headers
Gerald John M. Manipon | 1 Jun 2005 16:25
Picon
Picon
Favicon

build problem on solaris

Hello,

I compiled python 2.4.1 on a solaris 2.8 box using gcc 3.2.3.  When
I try to build Numeric 24.0b2, I get this error:

building 'RNG.RNG' extension
/usr/local/bin/gcc -fno-strict-aliasing -DNDEBUG -O -fPIC -IInclude 
-IPackages/FFT/Include -IPackages/RNG/Include 
-I/export/00/gmanipon/sciflo/include/python2.4 -c 
Packages/RNG/Src/ranf.c -o 
build/temp.solaris-2.8-sun4u-2.4/Packages/RNG/Src/ranf.o
Packages/RNG/Src/ranf.c: In function `Mixranf':
Packages/RNG/Src/ranf.c:153: conflicting types for `gettimeofday'
/usr/include/sys/time.h:390: previous declaration of `gettimeofday'
Packages/RNG/Src/ranf.c:153: warning: extern declaration of 
`gettimeofday' doesn't match global one
error: command '/usr/local/bin/gcc' failed with exit status 1

Has anyone encountered this problem?  Any help is greatly appreciated.

Gerald

-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
Permalink | Reply | 2 comments |
headers
David M. Cooke | 1 Jun 2005 16:59
Picon
Picon

Re: build problem on solaris

On Wed, Jun 01, 2005 at 07:25:47AM -0700, Gerald John M. Manipon wrote:
> Hello,
> 
> I compiled python 2.4.1 on a solaris 2.8 box using gcc 3.2.3.  When
> I try to build Numeric 24.0b2, I get this error:
> 
> building 'RNG.RNG' extension
> /usr/local/bin/gcc -fno-strict-aliasing -DNDEBUG -O -fPIC -IInclude 
> -IPackages/FFT/Include -IPackages/RNG/Include 
> -I/export/00/gmanipon/sciflo/include/python2.4 -c 
> Packages/RNG/Src/ranf.c -o 
> build/temp.solaris-2.8-sun4u-2.4/Packages/RNG/Src/ranf.o
> Packages/RNG/Src/ranf.c: In function `Mixranf':
> Packages/RNG/Src/ranf.c:153: conflicting types for `gettimeofday'
> /usr/include/sys/time.h:390: previous declaration of `gettimeofday'
> Packages/RNG/Src/ranf.c:153: warning: extern declaration of 
> `gettimeofday' doesn't match global one
> error: command '/usr/local/bin/gcc' failed with exit status 1
> 
> Has anyone encountered this problem?  Any help is greatly appreciated.

Could you add this as a bug to the bug tracker at
http://sourceforge.net/tracker/?group_id=1369&atid=101369
and assign it to me (dmcooke)? That ranf.c file is full of
platform-specific tweaks for handling the time, which shouldn't be
necessary (really, if it wants the time, it should use the Python time
module).

I'd just edit Packages/RNG/Src/ranf.c, and delete the declaration
of gettimeofday. From what I could google about Solaris's gettimeofday,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gerald John M. Manipon | 1 Jun 2005 17:15
Picon
Picon
Favicon

Re: build problem on solaris

Done, but it was assigned id 1212776.  Anyways,
I did what you said and it compiled fine.  I ran
the tests and no errors came up.

Thanks!

Gerald

David M. Cooke wrote:
> On Wed, Jun 01, 2005 at 07:25:47AM -0700, Gerald John M. Manipon wrote:
> 
>>Hello,
>>
>>I compiled python 2.4.1 on a solaris 2.8 box using gcc 3.2.3.  When
>>I try to build Numeric 24.0b2, I get this error:
>>
>>building 'RNG.RNG' extension
>>/usr/local/bin/gcc -fno-strict-aliasing -DNDEBUG -O -fPIC -IInclude 
>>-IPackages/FFT/Include -IPackages/RNG/Include 
>>-I/export/00/gmanipon/sciflo/include/python2.4 -c 
>>Packages/RNG/Src/ranf.c -o 
>>build/temp.solaris-2.8-sun4u-2.4/Packages/RNG/Src/ranf.o
>>Packages/RNG/Src/ranf.c: In function `Mixranf':
>>Packages/RNG/Src/ranf.c:153: conflicting types for `gettimeofday'
>>/usr/include/sys/time.h:390: previous declaration of `gettimeofday'
>>Packages/RNG/Src/ranf.c:153: warning: extern declaration of 
>>`gettimeofday' doesn't match global one
>>error: command '/usr/local/bin/gcc' failed with exit status 1
>>
>>Has anyone encountered this problem?  Any help is greatly appreciated.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adrian E. Feiguin | 2 Jun 2005 00:37
Picon
Favicon

API broken after 1.1.1 (previously "crashes after switching to 1.3.x")

Hi,

As I've been discussing withTodd, scigraphica crashes after switching to 
a newer version of numarray. I checked that it does not crash with 
Numeric, or numarray-1.1.1, so I figured that at some point something 
was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 
some change broke the API. What I mean is that my libraries simply fail 
to load numarray. I did diff between headers, and the only relevant 
change that I noticed between 1.1.1 and 1.2.3 that I guess could be 
related to this problem is in libnumeric.h:

132c132
< static int  PyArray_Converter  (PyObject *, PyObject **);
---
 > static int  XXX_PyArray_Converter  (PyObject *, PyObject **);
140c140
< static int  PyArray_ValidType  (int type);
---
 > static int  XXX_PyArray_ValidType  (int type);
208c208
< #define  PyArray_Converter (libnumeric_API ? (*(int (*)  (PyObject *, 
PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*)  (PyObject *, PyObject 
**) ) libnumeric_FatalApiError))
---
 > #define  XXX_PyArray_Converter (libnumeric_API ? (*(int (*)  
(PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*)  
(PyObject *, PyObject **) ) libnumeric_FatalApiError))
216c216
< #define  PyArray_ValidType (libnumeric_API ? (*(int (*)  (int type) ) 
libnumeric_API[ 29 ]) : (*(int (*)  (int type) ) libnumeric_FatalApiError))
(Continue reading)

Permalink | Reply | 7 comments |
headers
Sebastian Haase | 2 Jun 2005 02:37
Picon

Re: API broken after 1.1.1 (previously "crashes after switching to 1.3.x")

Hi,
I just feel that this is probably the same problem I had discovered already in 
February. Please refer to my discussions with Todd on this list.
Subject: [Numpy-discussion] Re: ANN: numarray-1.2.3  -- segfault in in my C 
program
Dates: 2005-03-03  and 2005-05-09, 2005-05-10

I did not find out what the problem is.
I do not have a fix or workaround.

I would be very happy if this could be sorted out ;-)

Thanks,
Sebastian Haase

On Wednesday 01 June 2005 15:37, Adrian E. Feiguin wrote:
> Hi,
>
> As I've been discussing withTodd, scigraphica crashes after switching to
> a newer version of numarray. I checked that it does not crash with
> Numeric, or numarray-1.1.1, so I figured that at some point something
> was broken. It seems that at some point between numarray-1.1.1 and 1.2.3
> some change broke the API. What I mean is that my libraries simply fail
> to load numarray. I did diff between headers, and the only relevant
> change that I noticed between 1.1.1 and 1.2.3 that I guess could be
> related to this problem is in libnumeric.h:
>
> 132c132
> < static int  PyArray_Converter  (PyObject *, PyObject **);
> ---
(Continue reading)

Permalink | Reply | 0 comments |
headers
Todd Miller | 3 Jun 2005 00:14

Re: API broken after 1.1.1 (previously "crashes after switching to 1.3.x")

I looked over your diffs but I don't think they're related to the
problem you're seeing.  

>From your previous posts and those of Sebastian,  I had the impression
that you're using numarray in an embedded context... so  I found
embedded "from numarray import *".  

I learned that numarray embedding "broke" for numarray-1.2.3 by adding
the unnecessary requirement that sys.argv exist.  I fixed this in
numarray CVS.  A possible alternative to my fix which should work for
older versions of numarray is to call PySys_SetArgv(0,NULL) after
Py_Initialize() to ensure that sys.argv exists.

Regards,
Todd

On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote:
> Hi,
> 
> As I've been discussing withTodd, scigraphica crashes after switching to 
> a newer version of numarray. I checked that it does not crash with 
> Numeric, or numarray-1.1.1, so I figured that at some point something 
> was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 
> some change broke the API. What I mean is that my libraries simply fail 
> to load numarray. I did diff between headers, and the only relevant 
> change that I noticed between 1.1.1 and 1.2.3 that I guess could be 
> related to this problem is in libnumeric.h:
> 
> 132c132
> < static int  PyArray_Converter  (PyObject *, PyObject **);
(Continue reading)

Permalink | Reply | 5 comments |
headers
Adrian E. Feiguin | 3 Jun 2005 01:11
Picon
Favicon

Re: API broken after 1.1.1 (previously "crashes after switching to 1.3.x")

Hi Todd,

I compiled the cvs version and it seems that you have fixed the problem, 
excellent! However, your "fix" for older versions doesn't work, any 
suggestions?

Thanks!
<ADRIAN>

Todd Miller wrote:

>I looked over your diffs but I don't think they're related to the
>problem you're seeing.  
>
>>From your previous posts and those of Sebastian,  I had the impression
>that you're using numarray in an embedded context... so  I found
>embedded "from numarray import *".  
>
>I learned that numarray embedding "broke" for numarray-1.2.3 by adding
>the unnecessary requirement that sys.argv exist.  I fixed this in
>numarray CVS.  A possible alternative to my fix which should work for
>older versions of numarray is to call PySys_SetArgv(0,NULL) after
>Py_Initialize() to ensure that sys.argv exists.
>
>Regards,
>Todd
>
>On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote:
>  
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Sebastian Haase | 3 Jun 2005 02:43
Picon

Re: API broken after 1.1.1 (previously "crashes after switching to 1.3.x")

Hi,
Great, my long tested program works now again.
I still don't know what the gcc option -fPIC is for. Also "-shared" is not 
clear to me. (From the discussion before: I don't use it, seg-fault if I do)
I anyone here could teach me ...

In any case, I'm happy again.
Thanks,
Sebastian Haase

On Thursday 02 June 2005 16:11, Adrian E. Feiguin wrote:
> Hi Todd,
>
> I compiled the cvs version and it seems that you have fixed the problem,
> excellent! However, your "fix" for older versions doesn't work, any
> suggestions?
>
> Thanks!
> <ADRIAN>
>
> Todd Miller wrote:
> >I looked over your diffs but I don't think they're related to the
> >problem you're seeing.
> >
> >>From your previous posts and those of Sebastian,  I had the impression
> >
> >that you're using numarray in an embedded context... so  I found
> >embedded "from numarray import *".
> >
> >I learned that numarray embedding "broke" for numarray-1.2.3 by adding
(Continue reading)

Permalink | Reply | 0 comments |
headers
Todd Miller | 3 Jun 2005 15:27

Re: API broken after 1.1.1 (previously "crashes after switching to 1.3.x")

On Thu, 2005-06-02 at 19:11, Adrian E. Feiguin wrote:
> Hi Todd,
> 
> I compiled the cvs version and it seems that you have fixed the problem, 
> excellent! However, your "fix" for older versions doesn't work, any 
> suggestions?

Try this instead (or get and use the "real" argc, argv):

PySys_SetArgv(0, &"");

Todd

> Thanks!
> <ADRIAN>
> 
> Todd Miller wrote:
> 
> >I looked over your diffs but I don't think they're related to the
> >problem you're seeing.  
> >
> >>From your previous posts and those of Sebastian,  I had the impression
> >that you're using numarray in an embedded context... so  I found
> >embedded "from numarray import *".  
> >
> >I learned that numarray embedding "broke" for numarray-1.2.3 by adding
> >the unnecessary requirement that sys.argv exist.  I fixed this in
> >numarray CVS.  A possible alternative to my fix which should work for
> >older versions of numarray is to call PySys_SetArgv(0,NULL) after
> >Py_Initialize() to ensure that sys.argv exists.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Adrian E. Feiguin | 3 Jun 2005 19:56
Picon
Favicon

Re: API broken after 1.1.1 (previously "crashes after switching to 1.3.x")

That worked, thanks! BTW, Are you planning to release soon?
aludos,
<ADRIAN>

Todd Miller wrote:

>On Thu, 2005-06-02 at 19:11, Adrian E. Feiguin wrote:
>  
>
>>Hi Todd,
>>
>>I compiled the cvs version and it seems that you have fixed the problem, 
>>excellent! However, your "fix" for older versions doesn't work, any 
>>suggestions?
>>    
>>
>
>Try this instead (or get and use the "real" argc, argv):
>
>PySys_SetArgv(0, &"");
>
>
>Todd
>
>  
>
>>Thanks!
>><ADRIAN>
>>
>>Todd Miller wrote:
(Continue reading)

Permalink | Reply | 1 comment |

Gmane