Problem building Sage on FreeBSD

[Jean-Pierre Flori]

Dear all,

I'm currently trying to build Sage on FreeBSD and the eclib spkg failed because it uses int64_t in eclib/xmod.h.
Including <inttypes.h> there solves the problem.
I guess it's using the Sage's GCC.
Is this a known issue?
Looking at http://www.freebsd.org/cgi/cvsweb.cgi/ports/math/sage/ and with my limited knowledge of ports, it does not seem such a fix is included.

Best,
JP

[Julien Puydt]

Le 04/04/2013 17:52, Jean-Pierre Flori a �crit :

> I'm currently trying to build Sage on FreeBSD and the eclib spkg failed
> because it uses int64_t in eclib/xmod.h.
> Including <inttypes.h> there solves the problem.

I think int64_t is supposed to come from stdint.h, and it's standard:
http://en.wikibooks.org/wiki/C_Programming/C_Reference/stdint.h

I hope that helps,

Snark on #sagemath

[Jean-Pierre Flori]

On Thursday, April 4, 2013 6:22:43 PM UTC+2, Snark wrote:

Le 04/04/2013 17:52, Jean-Pierre Flori a �crit :

> I'm currently trying to build Sage on FreeBSD and the eclib spkg failed
> because it uses int64_t in eclib/xmod.h.
> Including <inttypes.h> there solves the problem.

I think int64_t is supposed to come from stdint.h, and it's standard:
http://en.wikibooks.org/wiki/C_Programming/C_Reference/stdint.h

I hope that helps,

Thanks.

Indeed, including inttypes.h solves the issue because it itself includes stdint.h where this is defined.
Maybe some C99 hell on FreeBSD or with the GCC Sage built there, I don't know.

What I'd like to know is if anyone encountered a similar problem (on FreeBSD or elsewhere).
It's the first time I give FreeBSD a try and I've never encountered this issue anywhere else...
Maybe Stephen who takes care of the FreeBSD port has something to say :)

[Volker Braun]

Maybe something like -D__C99FEATURES__ works? See #14265

[Jean-Pierre Flori]

On Thursday, April 4, 2013 6:43:13 PM UTC+2, Volker Braun wrote:

Maybe something like -D__C99FEATURES__ works? See #14265

Good idea I'll give it a shot.

[Jean-Pierre Flori]

And nope, its not working.

[Jeroen Demeyer]

OK, so the solution is easy: add
#include <stdint.h>

No need to look further, I'd say...

[Jean-Pierre Flori]

What I find disturbing is that I never encountered it anwhere else.

[Jeroen Demeyer]

It seems that some compilers/C libraries are more lenient than others...

[leif]

Jean-Pierre Flori wrote:
> On Thursday, April 4, 2013 6:22:43 PM UTC+2, Snark wrote:
>

> Le 04/04/2013 17:52, Jean-Pierre Flori a �crit :

> > I'm currently trying to build Sage on FreeBSD and the eclib spkg
> failed
> > because it uses int64_t in eclib/xmod.h.
> > Including <inttypes.h> there solves the problem.

Hard to tell without a configure / build log.

> I think int64_t is supposed to come from stdint.h, and it's standard:
> http://en.wikibooks.org/wiki/C_Programming/C_Reference/stdint.h
> <http://en.wikibooks.org/wiki/C_Programming/C_Reference/stdint.h>
>
> I hope that helps,
>
> Thanks.
> Indeed, including inttypes.h solves the issue because it itself includes
> stdint.h where this is defined.
> Maybe some C99 hell on FreeBSD or with the GCC Sage built there, I don't
> know.

Well, eclib is C++. My guess is that on all other systems, stdint.h (or
cstdint) gets pulled in by some other directly or indirectly included
header file.

But note that in xmod.h, there's also

#ifdef USE_DMOD

// code not using int64_t

#else

// code using int64_t

#endif

(I haven't found traces of USE_DMOD in my build log though.)


In any case, including cstdint in the '#else' branch shouldn't hurt
(although it's probably really a FreeBSD bug, or at least your
installation is somehow broken -- we haven't had problems on Solaris...
;-) ).


-leif

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[leif]

leif wrote:
> Jean-Pierre Flori wrote:
>> On Thursday, April 4, 2013 6:22:43 PM UTC+2, Snark wrote:
>>
>> Le 04/04/2013 17:52, Jean-Pierre Flori a �crit :
>> > I'm currently trying to build Sage on FreeBSD and the eclib spkg
>> failed
>> > because it uses int64_t in eclib/xmod.h.
>> > Including <inttypes.h> there solves the problem.
>
> Hard to tell without a configure / build log.
>
>
>> I think int64_t is supposed to come from stdint.h, and it's standard:
>> http://en.wikibooks.org/wiki/C_Programming/C_Reference/stdint.h
>> <http://en.wikibooks.org/wiki/C_Programming/C_Reference/stdint.h>
>>
>> I hope that helps,
>>
>> Thanks.
>> Indeed, including inttypes.h solves the issue because it itself includes
>> stdint.h where this is defined.
>> Maybe some C99 hell on FreeBSD or with the GCC Sage built there, I don't
>> know.
>
> Well, eclib is C++. My guess is that on all other systems, stdint.h (or
> cstdint) gets pulled in by some other directly or indirectly included
> header file.

FWIW, here on Linux <algorithm> (included by "interface.h") pulls in
<sys/types.h> [indirectly, of course^TM], which defines int64_t et al.

(xmod.h is only included by arith.h, which in turn includes interface.h,
before xmod.h.)

Or otherwise ask John Cremona... ;-)


-leif

[leif]

leif wrote:
> FWIW, here on Linux <algorithm> (included by "interface.h") pulls in
> <sys/types.h> [indirectly, of course^TM], which defines int64_t et al.

The same (or, more precisely, similar) is true on Solaris.


-leif

> (xmod.h is only included by arith.h, which in turn includes interface.h,
> before xmod.h.)
>
> Or otherwise ask John Cremona... ;-)
>
>
> -leif

[Julien Puydt]

Le 05/04/2013 03:28, leif a écrit :
> Or otherwise ask John Cremona... ;-)

I suggest to provide him a patch adding the #include at the top of one
of the files.

If he didn't already answer, that means he's busy :-)

Snark on #sagemath

[leif]

Julien Puydt wrote:
> Le 05/04/2013 03:28, leif a �crit :

>> Or otherwise ask John Cremona... ;-)
>
> I suggest to provide him a patch adding the #include at the top of one
> of the files.

Yep, but better where int64_t is actually used, i.e., in the mentioned
#else part in xmod.h, and probably some other places (see below).

> If he didn't already answer, that means he's busy :-)

No, he's having fun watching us guessing. ;-)


-leif


P.S.:

Apparently int64_t is also used in libsrc/smat_elim.cc,
libsrc/smat.cc and libsrc/svec.cc; haven't checked which files include
these, or where these get the definition from.

[Julien Puydt]

Le 05/04/2013 07:29, leif a �crit :

> Julien Puydt wrote:
>> Le 05/04/2013 03:28, leif a �crit :
>>> Or otherwise ask John Cremona... ;-)
>>
>> I suggest to provide him a patch adding the #include at the top of one
>> of the files.
>
> Yep, but better where int64_t is actually used, i.e., in the mentioned
> #else part in xmod.h, and probably some other places (see below).

I'm not sure it makes sense to over-optimize where the file is included:
it's a system include widely available, so there's little interest to
restrict its visibility.

> P.S.:
>
> Apparently int64_t is also used in libsrc/smat_elim.cc,
> libsrc/smat.cc and libsrc/svec.cc; haven't checked which files include
> these, or where these get the definition from.

So you see my point about just including it at the top of one of the
main headers of eclib and be done :-P

Snark on #sagemath

[Jean-Pierre Flori]

On Friday, April 5, 2013 7:37:20 AM UTC+2, Snark wrote:

Le 05/04/2013 07:29, leif a �crit :
> Julien Puydt wrote:
>> Le 05/04/2013 03:28, leif a �crit :

>>> Or otherwise ask John Cremona... ;-)
>>
>> I suggest to provide him a patch adding the #include at the top of one
>> of the files.
>
> Yep, but better where int64_t is actually used, i.e., in the mentioned
> #else part in xmod.h, and probably some other places (see below).

I'm not sure it makes sense to over-optimize where the file is included:
it's a system include widely available, so there's little interest to
restrict its visibility.

I think including <stdint.h> at the top of xmod.h is fine and works fine.
the other files using int64_t are included from files including arith.h which include xmod.h.

[Jean-Pierre Flori]

For the record, I got trouble building R as well on the FreeBSD 9.0 x86.
First it cannot find iconv.h (which is a system wide one in /usr/include/sys).
Second, when I help it to find iconv.h, it complains iconv_t is undeclared.
I'll try to build Sage provided iconv and build R on top of that.

[Jean-Pierre Flori]

On Friday, April 5, 2013 2:04:58 PM UTC+2, Jean-Pierre Flori wrote:

For the record, I got trouble building R as well on the FreeBSD 9.0 x86.
First it cannot find iconv.h (which is a system wide one in /usr/include/sys).
Second, when I help it to find iconv.h, it complains iconv_t is undeclared.
I'll try to build Sage provided iconv and build R on top of that.

And that seems to work fine.

[Jean-Pierre Flori]

On Friday, April 5, 2013 2:05:30 PM UTC+2, Jean-Pierre Flori wrote:

On Friday, April 5, 2013 2:04:58 PM UTC+2, Jean-Pierre Flori wrote:

For the record, I got trouble building R as well on the FreeBSD 9.0 x86.
First it cannot find iconv.h (which is a system wide one in /usr/include/sys).
Second, when I help it to find iconv.h, it complains iconv_t is undeclared.
I'll try to build Sage provided iconv and build R on top of that.

And that seems to work fine.

(or rather at least it compiles the problematic file src/main/sysinclude.c (or a variation of that name))

[John Cremona]

OK, so I have been lurking but only just noticed that this thread was
relevant to me (of all the stupid things gmail chooses to display
to the right of messages, what it does not do as far as I know is
alert you to the occurrence of your name!)

I gather that I should add #include <stdint.h> at the top of xmod.h

Which line (see
https://github.com/JohnCremona/eclib/blob/master/libsrc/eclib/xmod.h)?

I'll be happy to do that right away, but will not have time today to
remake the spkg.

John

> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Jean-Pierre Flori]

On Friday, April 5, 2013 2:20:04 PM UTC+2, John Cremona wrote:

OK, so I have been lurking but only just noticed that this thread was
relevant to me    (of all the stupid things gmail chooses to display
to the right of messages, what it does not do as far as I know is
alert you to the occurrence of your name!)

I gather that I should add #include <stdint.h> at the top of xmod.h

Which line (see
https://github.com/JohnCremona/eclib/blob/master/libsrc/eclib/xmod.h)?

For the minimal modification, I'd say at line 29, just after
{{{

#ifndef _XMOD_H
#define _XMOD_H      1

}}}

But as leif pointed out, to make it more proper, you could want to put it at line 109 or 111, in the else part of
{{{

#ifdef USE_DMOD

// code not using int64_t

#else

!!! HERE !!!

// code using int64_t

#endif
}}}

But int64_t is also used in libsrc/smat_elim.cc, libsrc/smat.cc and libsrc/svec.cc whether DMOD is set or not.
These files are included in s*.cc which includes arith.h which includes xmod.h so if the stdint.h include is at line 29, it will be found, whether DMOD is set or not.
If it's at line 109, then you have to include it in libsrc/smat_elim.cc, libsrc/smat.cc and libsrc/svec.cc, or add DMOD logic to these file to not use int64_t when xmod.h does not, or whatever you prefer :)

And it's definitely not a real problem, take all your time!

Best,
JP

[Jeroen Demeyer]

On 04/05/2013 02:40 PM, Jean-Pierre Flori wrote:

> For the minimal modification, I'd say at line 29, just after
> {{{
>
> #ifndef _XMOD_H
> #define _XMOD_H 1
>
> }}}

I would go with the minimal modification, no need to make things more
complicated than needed.

[Jean-Pierre Flori]

I agree.

But maybe John wants the possibility to build a version not using int64_t at all.
That's not the case currently because of smat.cc, smat_elim.cc and svec.cc, but the use of DMOD in xmod.h tends to show he may have tought about that possibility at some point.

[John Cremona]

I probably did, but some of this code is rather old, and I have
tendency when redesigning something to leave the older versions in but
omitted via these preprocessor flags. It is quite possible (and in
fact rather likely) that some of these options no longer work anyway,
so I should probably clean the code up more than is being suggested,
eliminating redundant stuff which is distracting you all.

Once I switch to using FLINT more a lot of this careful coding for
modular arithmetic will probably redundant.

But I have other things to think about right now...

John

[Jean-Pierre Flori]

As the ATLAS 3.8.4 install was broken, I gave the 3.10.1 a try.
Same thread related undefined problem as on other exotic platforms with the shared library (at some point form numpy.linalg import lapack_lite will fail, typically during scipy build), so I'm trying with static ones (currently not installed by the spkg).
It seems alright, until scipy builds because it asks numy (from numpy.distutils.system_info import get_info) what the atlas libs are and numpy tells that atlas is name atlas_r (and lapack alapack_r) on freebsd.
Putting back atlas and lapack let the configuration finish, but it then fails later with:
/usr/lib/crt1.o: In function `_start1':
crt1_c.c:(.text+0xa3): undefined reference to `main'
collect2: error: ld returned 1 exit status
/usr/lib/crt1.o: In function `_start1':
crt1_c.c:(.text+0xa3): undefined reference to `main'
collect2: error: ld returned 1 exit status
error: Command "/scratch/jpflori/sage-5.9.beta4-freebsd-90-x86/local/bin/gfortran -Wall build/temp.freebsd-9.0-RELEASE-i386-2.7/build/src.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/_fftpackmodule.o build/temp.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/src/zfft.o build/temp.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/src/drfft.o build/temp.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/src/zrfft.o build/temp.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/src/zfftnd.o build/temp.freebsd-9.0-RELEASE-i386-2.7/build/src.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/src/dct.o build/temp.freebsd-9.0-RELEASE-i386-2.7/build/src.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/src/dst.o build/temp.freebsd-9.0-RELEASE-i386-2.7/build/src.freebsd-9.0-RELEASE-i386-2.7/fortranobject.o -L/scratch/jpflori/sage-5.9.beta4-freebsd-90-x86/local/lib/gcc/i386-unknown-freebsd9.0/4.7.2 -Lbuild/temp.freebsd-9.0-RELEASE-i386-2.7 -ldfftpack -lfftpack -lpython2.7 -lgfortran -o build/lib.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/_fftpack.so" failed with exit status 1

[Jean-Pierre Flori]

On Friday, April 5, 2013 9:42:38 PM UTC+2, Jean-Pierre Flori wrote:

As the ATLAS 3.8.4 install was broken, I gave the 3.10.1 a try.
Same thread related undefined problem as on other exotic platforms with the shared library (at some point form numpy.linalg import lapack_lite will fail, typically during scipy build), so I'm trying with static ones (currently not installed by the spkg).
It seems alright, until scipy builds because it asks numy (from numpy.distutils.system_info import get_info) what the atlas libs are and numpy tells that atlas is name atlas_r (and lapack alapack_r) on freebsd.
Putting back atlas and lapack let the configuration finish, but it then fails later with:
/usr/lib/crt1.o: In function `_start1':
crt1_c.c:(.text+0xa3): undefined reference to `main'
collect2: error: ld returned 1 exit status
/usr/lib/crt1.o: In function `_start1':
crt1_c.c:(.text+0xa3): undefined reference to `main'
collect2: error: ld returned 1 exit status
error: Command "/scratch/jpflori/sage-5.9.beta4-freebsd-90-x86/local/bin/gfortran -Wall build/temp.freebsd-9.0-RELEASE-i386-2.7/build/src.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/_fftpackmodule.o build/temp.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/src/zfft.o build/temp.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/src/drfft.o build/temp.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/src/zrfft.o build/temp.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/src/zfftnd.o build/temp.freebsd-9.0-RELEASE-i386-2.7/build/src.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/src/dct.o build/temp.freebsd-9.0-RELEASE-i386-2.7/build/src.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/src/dst.o build/temp.freebsd-9.0-RELEASE-i386-2.7/build/src.freebsd-9.0-RELEASE-i386-2.7/fortranobject.o -L/scratch/jpflori/sage-5.9.beta4-freebsd-90-x86/local/lib/gcc/i386-unknown-freebsd9.0/4.7.2 -Lbuild/temp.freebsd-9.0-RELEASE-i386-2.7 -ldfftpack -lfftpack -lpython2.7 -lgfortran -o build/lib.freebsd-9.0-RELEASE-i386-2.7/scipy/fftpack/_fftpack.so" failed with exit status 1

I guess its just missing a -shared flag.

[Jean-Pierre Flori]

And once again its numpy.distutils.fcompiler.gnu whcih does not pass "-shared" in linker_so.