[sage-devel] Re: Problems building Sage

[Alyssa Russell]

Hi Samuel, 

Thank you for your reply! I tried your suggestion and I was still running 
into the same problem. However, I tried installing some other packages on 
top of what you suggested, which seemed to do the trick. These packages 
are  idle39 , 
python39-debuginfo 
, 
python39-devel , 
python39-test , and 
python39-tkinter . 
I'm not really sure why this worked, but nonetheless SageMath is now up and 
running! I'm now going to figure out how to run it on Jupyter Notebooks. I 
used SathMath 9.5.rc1 by the way.

--Alyssa

On Friday, January 14, 2022 at 1:40:13 PM UTC-8 Samuel Lelievre wrote:

> Hello, congratulations for attempting to build Sage
> from source on Cygwin and thanks for reporting on
> the build failure.
>
> Which version of Sage were you trying to build?
> Did you try SageMath 9.4 or SageMath 9.5.rc1?
>
> Fixing the Python 3.9 build failure you described is tracked at:
>
>   Sage Trac ticket #33079
>   Fix python3 build failure on Cygwin
>   https://trac.sagemath.org/ticket/33079
>
> In general, Sage's build mechanism tries to use the ambient
> system Python, if available, to avoid building its own Python.
> However, the Python 3.9 in Cygwin, currently provided by the
> Cygwin package "python39-3.9.9-1", does not work for that
> purpose. That issue is discussed at:
>
>   Sage Trac ticket #33078
>   Update package info for system python3 on Cygwin
>   https://trac.sagemath.org/ticket/33078
>
> There is a newer version which can serve to build Sage upon;
> that newer version is currently marked as a test version, so that
> it does not get installed by default when you upgrade your Cygwin
> packages. You can however choose to upgrade to it, as follows.
>
> - Close all Cygwin windows.
> - Open Cygwin's "setup.exe" installer, search for "python39",
>   and select the version "python39-3.9.9-3 (TEST)".
>
> Please try again building SageMath 9.5.rc1 after changing that.
> Let us know if that works. Currently it does not work for me,
> but I hope it works for you, and if not I hope we gather enough
> data on the failure to figure out how to solve it.   --Samuel
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d2094fb2-0817-4bcc-8663-3ba4abb6efbfn%40googlegroups.com.

[sage-devel] Re: Problems building Sage

[Samuel Lelievre]

Hello, congratulations for attempting to build Sage
from source on Cygwin and thanks for reporting on
the build failure.

Which version of Sage were you trying to build?
Did you try SageMath 9.4 or SageMath 9.5.rc1?

Fixing the Python 3.9 build failure you described is tracked at:

  Sage Trac ticket #33079
  Fix python3 build failure on Cygwin
  https://trac.sagemath.org/ticket/33079

In general, Sage's build mechanism tries to use the ambient
system Python, if available, to avoid building its own Python.
However, the Python 3.9 in Cygwin, currently provided by the
Cygwin package "python39-3.9.9-1", does not work for that
purpose. That issue is discussed at:

  Sage Trac ticket #33078
  Update package info for system python3 on Cygwin
  https://trac.sagemath.org/ticket/33078

There is a newer version which can serve to build Sage upon;
that newer version is currently marked as a test version, so that
it does not get installed by default when you upgrade your Cygwin
packages. You can however choose to upgrade to it, as follows.

- Close all Cygwin windows.
- Open Cygwin's "setup.exe" installer, search for "python39",
  and select the version "python39-3.9.9-3 (TEST)".

Please try again building SageMath 9.5.rc1 after changing that.
Let us know if that works. Currently it does not work for me,
but I hope it works for you, and if not I hope we gather enough
data on the failure to figure out how to solve it.   --Samuel

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0b9bfc45-cf21-453b-b926-a3ce7e5b8d95n%40googlegroups.com.

Re: [sage-devel] Re: problems building sage 4.7.2.rc0

[Pablo De Napoli]

Yes, that was exactly what happend!
a second make worked!
and I don't know why!

On Tue, Oct 25, 2011 at 6:21 PM, leif  wrote:
> On 25 Okt., 21:24, Pablo De Napoli  wrote:
>> I've tried to build Sage 4.7.2 rc0 on a 64 bits Debian GNU/Linux (wheezy/sig)
>> [Intel core I5 procesor]
>>
>> The build failed (compiling Atlas)
>> Here are the eror messages
>>
>> Thread model: posix
>> gcc version 4.6.1 (Debian 4.6.1-15)
>> gcc -V 2>&1  >> bin/INSTALL_LOG/ERROR.LOG
>> gcc: error: unrecognized option ‘-V’
>> gcc: fatal error: no input files
>> compilation terminated.
>> make[6]: [error_report] Error 4 (no tiene efecto)
>> gcc --version 2>&1  >> bin/INSTALL_LOG/ERROR.LOG
>> tar cf error_Corei264SSE3.tar Make.inc bin/INSTALL_LOG/*
>> gzip --best error_Corei264SSE3.tar
>> mv error_Corei264SSE3.tar.gz error_Corei264SSE3.tgz
>> make[6]: se sale del directorio
>> `/home/pablo/sage/sage-4.7.2.rc0/spkg/build/atlas-3.8.4/ATLAS-build'
>> make[5]: se sale del directorio
>> `/home/pablo/sage/sage-4.7.2.rc0/spkg/build/atlas-3.8.4/ATLAS-build'
>> make[4]: se sale del directorio
>> `/home/pablo/sage/sage-4.7.2.rc0/spkg/build/atlas-3.8.4/ATLAS-build/bin'
>> Error report error_.tgz has been created in your top-level ATLAS
>> directory.  Be sure to include this file in any help request.
>> cat: ../../CONFIG/error.txt: No existe el fichero o el directorio
>> cat: ../../CONFIG/error.txt: No existe el fichero o el directorio
>>
>> IN STAGE 1 INSTALL:  SYSTEM PROBE/AUX COMPILE
>> make[3]: *** [build] Error 255
>> make[3]: se sale del directorio
>> `/home/pablo/sage/sage-4.7.2.rc0/spkg/build/atlas-3.8.4/ATLAS-build'
>> make[2]: *** [build] Error 2
>> make[2]: se sale del directorio
>> `/home/pablo/sage/sage-4.7.2.rc0/spkg/build/atlas-3.8.4/ATLAS-build'
>>
>> My version of gcc is:
>>
>> $ gcc --version
>> gcc (Debian 4.6.1-15) 4.6.1
>> Copyright (C) 2011 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> gcc -V gives
>>
>> gcc -V
>> gcc: error: unrecognized option ‘-V’
>> gcc: fatal error: no input files
>> compilation terminated.
>
> Well, the error occurred earlier.  ATLAS then simply tries to get the
> compiler's version for the error report, which finally succeeds.
>
> As the log says, the relevant messages / ATLAS build logs are in
> "error_Corei264SSE3.tgz".
>
> Sometimes just doing a second build attempt (by simply typing 'make')
> succeeds.  Assuming you've disabled CPU throttling, aka power saving
> mode.  Also the system load shouldn't be too high when building ATLAS.
>
>
> -leif
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to 
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: problems building sage 4.7.2.rc0

[leif]

On 25 Okt., 21:24, Pablo De Napoli  wrote:
> I've tried to build Sage 4.7.2 rc0 on a 64 bits Debian GNU/Linux (wheezy/sig)
> [Intel core I5 procesor]
>
> The build failed (compiling Atlas)
> Here are the eror messages
>
> Thread model: posix
> gcc version 4.6.1 (Debian 4.6.1-15)
> gcc -V 2>&1  >> bin/INSTALL_LOG/ERROR.LOG
> gcc: error: unrecognized option ‘-V’
> gcc: fatal error: no input files
> compilation terminated.
> make[6]: [error_report] Error 4 (no tiene efecto)
> gcc --version 2>&1  >> bin/INSTALL_LOG/ERROR.LOG
> tar cf error_Corei264SSE3.tar Make.inc bin/INSTALL_LOG/*
> gzip --best error_Corei264SSE3.tar
> mv error_Corei264SSE3.tar.gz error_Corei264SSE3.tgz
> make[6]: se sale del directorio
> `/home/pablo/sage/sage-4.7.2.rc0/spkg/build/atlas-3.8.4/ATLAS-build'
> make[5]: se sale del directorio
> `/home/pablo/sage/sage-4.7.2.rc0/spkg/build/atlas-3.8.4/ATLAS-build'
> make[4]: se sale del directorio
> `/home/pablo/sage/sage-4.7.2.rc0/spkg/build/atlas-3.8.4/ATLAS-build/bin'
> Error report error_.tgz has been created in your top-level ATLAS
> directory.  Be sure to include this file in any help request.
> cat: ../../CONFIG/error.txt: No existe el fichero o el directorio
> cat: ../../CONFIG/error.txt: No existe el fichero o el directorio
>
> IN STAGE 1 INSTALL:  SYSTEM PROBE/AUX COMPILE
> make[3]: *** [build] Error 255
> make[3]: se sale del directorio
> `/home/pablo/sage/sage-4.7.2.rc0/spkg/build/atlas-3.8.4/ATLAS-build'
> make[2]: *** [build] Error 2
> make[2]: se sale del directorio
> `/home/pablo/sage/sage-4.7.2.rc0/spkg/build/atlas-3.8.4/ATLAS-build'
>
> My version of gcc is:
>
> $ gcc --version
> gcc (Debian 4.6.1-15) 4.6.1
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> gcc -V gives
>
> gcc -V
> gcc: error: unrecognized option ‘-V’
> gcc: fatal error: no input files
> compilation terminated.

Well, the error occurred earlier.  ATLAS then simply tries to get the
compiler's version for the error report, which finally succeeds.

As the log says, the relevant messages / ATLAS build logs are in
"error_Corei264SSE3.tgz".

Sometimes just doing a second build attempt (by simply typing 'make')
succeeds.  Assuming you've disabled CPU throttling, aka power saving
mode.  Also the system load shouldn't be too high when building ATLAS.


-leif

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Problems building Sage 4.4.1

[Dr. David Kirkby]

On 06/11/10 06:34 PM, Matthew Gwynne wrote:

Thanks for the response! We'll try to disable it for now, and
investigate some of the other things mentioned in this thread.

The problem we have is that we need to provide something like CC/CXX
flags, as the only compiler we can guarantee is the one which we
install, which is installed in a specific location, not globally. Is
there some way we can do something similar to this in Sage? You said
that CC/CXX do not work very well, why is this :(?

Thanks!

Matthew


CC, CXX, CFLAGS and similar should be considered broken. If CC is undefined, 
Sage environment script sets CC to "gcc". If CXX is not defined, Sage 
environment script sets CXX to "g++", That seems logical.


However, if CC is defined, the Sage environment script does not change it. Again 
this seems logical.


When the individual components of Sage are built, some well behaved packages 
respect these, and use the respective compiles. A large number do not, and use 
"gcc" or "g++"


So if you set

$ CC=/path/to/my/favorite/gcc

some programs will use the first "gcc" in the path and others will use 
/path/to/my/favorite/gcc. It is hit-and-miss


Over the course of time, I've filed loads of bug reports for these, and fixed 
some of them. The easiest way to find them, is to install the Sun compiler, then 
let type make, and detect what packages build with gcc. Many do unfortunately.


These are all outstanding.

http://trac.sagemath.org/sage_trac/ticket/7071
http://trac.sagemath.org/sage_trac/ticket/7069
http://trac.sagemath.org/sage_trac/ticket/7066
http://trac.sagemath.org/sage_trac/ticket/7027
http://trac.sagemath.org/sage_trac/ticket/7024

I've fixed a few

http://trac.sagemath.org/sage_trac/ticket/7036
http://trac.sagemath.org/sage_trac/ticket/7032

but there are many more. Fixing them is not always easy.


Your best course of action is to make sure your path is set correctly and 
perhaps LD_LIBRARY_PATH are set correctly to find the right compiler, so when 
you type just "gcc" you get a workable compiler.


Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Problems building Sage 4.4.1

[Matthew Gwynne]

Thanks for the response! We'll try to disable it for now, and
investigate some of the other things mentioned in this thread.

The problem we have is that we need to provide something like CC/CXX
flags, as the only compiler we can guarantee is the one which we
install, which is installed in a specific location, not globally. Is
there some way we can do something similar to this in Sage? You said
that CC/CXX do not work very well, why is this :(?

Thanks!

Matthew

On Jun 8, 6:21 pm, David Kirkby  wrote:
> On 8 June 2010 17:17, Matthew Gwynne  wrote:
>
> > Hi,
>
> > As some additional points of interest/questions for this problem:
>
> > 1. Version 2.7.2 was the lastSageversion which could be installed.
> > We tried most versions since then (latest 4.4.2), and they all failed
> > with the same error.
>
> Looking at the error message:
>
> -
> /usr/local/lib/../lib/libstdc++.so: could not read symbols: File in
> wrong format
> collect2: ld returned 1 exit status
> make[4]: *** [libfplll.la] Error 1
> -
>
> it rather suggests the compiler is complaining about a file in
> /usr/local, rather than one in theSagedirectory. It's quite possible
> that libfplll is the first package to link to the C++ library, which
> is what that file is.
>
> I would consider downloading gcc 4.4.4 (not 4.5, as that is quite new,
> and probably more buggy than the 4.4 series), and compiling that. You
> would also need to download mpfr and gmp, and build those.
>
> It's difficult to suggest much more. I'm not a linux guru, but had I
> hit the same message on the Solaris operating system, I would suspect
> the compiler. (Not that I claim to be a Solaris guru!)
>
> It's clear different parts of your compiler were built at different
> times, as your C and C++ compilers were built without Fortran support,
> and the Fortran compiler was built with C, C++ and Fortran support.
> That in itself should not stop the combination working, but I'd
> certainly look at trying another compiler.
>
> > 2. It is always the same package which fails. We don't have any other
> > installation problems in our system, so we wonder if that package
> > might be faulty in some way? Is there some difference with that
> > package compared to other packages (in theSage-build)?
>
> To be honest, few packages are configured identically.
>
> > 3. Is that package needed? Is there some way we can prevent it from
> > being used/built?
>
> You can stop pacakge 'foobar' building by foolingSageinto believing
> the package is already installed. The way to do that is
>
> touch spkg/installed/foobar
>
> In the case of some packages, that will still allowSageto build, but
> certainly not all packages. I don't know for sure whether this would
> be essential or not to get some sort of workingSage.
>
> It would be useful to try this. You might find other packages fail
> with a similar error, which would make me even more suspicious it is a
> compiler problem.
>
> > Thanks again!
>
> > Matthew
>
> Sorry I can't be of much more help.
>
> Dave
>
>
>
>
>
> > On May 26, 2:54 pm, David Kirkby  wrote:
> >> On 26 May 2010 11:57, Matthew Gwynne  wrote:
>
> >> > Hi,
>
> >> > The system information is given below -
>
> >> > 
> >> > Host system
> >> > uname -a:
> >> > Linux cs-wsok 2.6.13-15.8-smp #1 SMP Tue Feb 7 11:07:24 UTC 2006
> >> > x86_64 x86_64 x86_64 GNU/Linux
> >> > 
> >> > 
> >> > CC Version
> >> > gcc -v
> >> > Using built-in specs.
> >> > Target: x86_64-unknown-linux-gnu
> >> > Configured with: ./configure --enable-languages=c,c++ --enable-
> >> > threads=posix --enable-shared
> >> > Thread model: posix
>
> >> Something is odd here. You need to have a compiler supporting Fortran,
> >> yet yours was compiled without Fortran support. I'm very surprised the
> >> 'prereq' script does not detect this, as it should check for a fortran
> >> compiler and confirm its the same version as the C and C++ compilers.
>
> >> So unless you have two installations of gcc, both of the same version,
> >> I don't know how you got this far.
>
> >> can you give me the outputs of
>
> >> $ command -v gcc
> >> $ command -v g++
> >> $ command -v gfortran
> >> $ gcc -v
> >> $ g++ -v
> >> $ gfortran -v
> >> $ echo $LD_LIBRARY_PATH
> >> $ echo $CC
> >> $ echo $CXX
> >> $ echo SAGE_FORTRAN
> >> $ echo SAGE_FORTRAN_LIB
>
> >> Specifying the compiler locations with CC and CXX does not work too well
>
> >> Dave
>
> > --
> > To post to this group, send an email tosage-de...@googlegroups.com
> > To unsubscribe from this group, send an email 
> > tosage-devel+unsubscr...@googlegroups.com
> > For more options, visit this group 
> > athttp://groups.google.com/group/sage-devel
> > URL:http://www.sagemath.org

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscr

Re: [sage-devel] Re: Problems building Sage 4.4.1

[David Kirkby]

On 8 June 2010 17:17, Matthew Gwynne  wrote:
> Hi,
>
> As some additional points of interest/questions for this problem:
>
> 1. Version 2.7.2 was the last Sage version which could be installed.
> We tried most versions since then (latest 4.4.2), and they all failed
> with the same error.

Looking at the error message:

-
/usr/local/lib/../lib/libstdc++.so: could not read symbols: File in
wrong format
collect2: ld returned 1 exit status
make[4]: *** [libfplll.la] Error 1
-

it rather suggests the compiler is complaining about a file in
/usr/local, rather than one in the Sage directory. It's quite possible
that libfplll is the first package to link to the C++ library, which
is what that file is.

I would consider downloading gcc 4.4.4 (not 4.5, as that is quite new,
and probably more buggy than the 4.4 series), and compiling that. You
would also need to download mpfr and gmp, and build those.

It's difficult to suggest much more. I'm not a linux guru, but had I
hit the same message on the Solaris operating system, I would suspect
the compiler. (Not that I claim to be a Solaris guru!)

It's clear different parts of your compiler were built at different
times, as your C and C++ compilers were built without Fortran support,
and the Fortran compiler was built with C, C++ and Fortran support.
That in itself should not stop the combination working, but I'd
certainly look at trying another compiler.

> 2. It is always the same package which fails. We don't have any other
> installation problems in our system, so we wonder if that package
> might be faulty in some way? Is there some difference with that
> package compared to other packages (in the Sage-build)?

To be honest, few packages are configured identically.


> 3. Is that package needed? Is there some way we can prevent it from
> being used/built?


You can stop pacakge 'foobar' building by fooling Sage into believing
the package is already installed. The way to do that is

touch spkg/installed/foobar

In the case of some packages, that will still allow Sage to build, but
certainly not all packages. I don't know for sure whether this would
be essential or not to get some sort of working Sage.

It would be useful to try this. You might find other packages fail
with a similar error, which would make me even more suspicious it is a
compiler problem.

> Thanks again!
>
> Matthew

Sorry I can't be of much more help.

Dave
>
> On May 26, 2:54 pm, David Kirkby  wrote:
>> On 26 May 2010 11:57, Matthew Gwynne  wrote:
>>
>>
>>
>>
>>
>> > Hi,
>>
>> > The system information is given below -
>>
>> > 
>> > Host system
>> > uname -a:
>> > Linux cs-wsok 2.6.13-15.8-smp #1 SMP Tue Feb 7 11:07:24 UTC 2006
>> > x86_64 x86_64 x86_64 GNU/Linux
>> > 
>> > 
>> > CC Version
>> > gcc -v
>> > Using built-in specs.
>> > Target: x86_64-unknown-linux-gnu
>> > Configured with: ./configure --enable-languages=c,c++ --enable-
>> > threads=posix --enable-shared
>> > Thread model: posix
>>
>> Something is odd here. You need to have a compiler supporting Fortran,
>> yet yours was compiled without Fortran support. I'm very surprised the
>> 'prereq' script does not detect this, as it should check for a fortran
>> compiler and confirm its the same version as the C and C++ compilers.
>>
>> So unless you have two installations of gcc, both of the same version,
>> I don't know how you got this far.
>>
>> can you give me the outputs of
>>
>> $ command -v gcc
>> $ command -v g++
>> $ command -v gfortran
>> $ gcc -v
>> $ g++ -v
>> $ gfortran -v
>> $ echo $LD_LIBRARY_PATH
>> $ echo $CC
>> $ echo $CXX
>> $ echo SAGE_FORTRAN
>> $ echo SAGE_FORTRAN_LIB
>>
>> Specifying the compiler locations with CC and CXX does not work too well
>>
>> Dave
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to 
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Problems building Sage 4.4.1

[Matthew Gwynne]

Hi,

As some additional points of interest/questions for this problem:

1. Version 2.7.2 was the last Sage version which could be installed.
We tried most versions since then (latest 4.4.2), and they all failed
with the same error.

2. It is always the same package which fails. We don't have any other
installation problems in our system, so we wonder if that package
might be faulty in some way? Is there some difference with that
package compared to other packages (in the Sage-build)?

3. Is that package needed? Is there some way we can prevent it from
being used/built?

Thanks again!

Matthew

On May 26, 2:54 pm, David Kirkby  wrote:
> On 26 May 2010 11:57, Matthew Gwynne  wrote:
>
>
>
>
>
> > Hi,
>
> > The system information is given below -
>
> > 
> > Host system
> > uname -a:
> > Linux cs-wsok 2.6.13-15.8-smp #1 SMP Tue Feb 7 11:07:24 UTC 2006
> > x86_64 x86_64 x86_64 GNU/Linux
> > 
> > 
> > CC Version
> > gcc -v
> > Using built-in specs.
> > Target: x86_64-unknown-linux-gnu
> > Configured with: ./configure --enable-languages=c,c++ --enable-
> > threads=posix --enable-shared
> > Thread model: posix
>
> Something is odd here. You need to have a compiler supporting Fortran,
> yet yours was compiled without Fortran support. I'm very surprised the
> 'prereq' script does not detect this, as it should check for a fortran
> compiler and confirm its the same version as the C and C++ compilers.
>
> So unless you have two installations of gcc, both of the same version,
> I don't know how you got this far.
>
> can you give me the outputs of
>
> $ command -v gcc
> $ command -v g++
> $ command -v gfortran
> $ gcc -v
> $ g++ -v
> $ gfortran -v
> $ echo $LD_LIBRARY_PATH
> $ echo $CC
> $ echo $CXX
> $ echo SAGE_FORTRAN
> $ echo SAGE_FORTRAN_LIB
>
> Specifying the compiler locations with CC and CXX does not work too well
>
> Dave

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Problems building Sage 4.4.1

[Matthew Gwynne]

Here is the output:

~> command -v gcc
/usr/local/bin/gcc
~> command -v g++
/usr/local/bin/g++
~> command -v gfortran
/usr/local/bin/gfortran
~> gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --enable-
threads=posix --enable-shared
Thread model: posix
gcc version 4.1.2
~> g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --enable-
threads=posix --enable-shared
Thread model: posix
gcc version 4.1.2
~> gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++,fortran --enable-
threads=posix --enable-shared
Thread model: posix
gcc version 4.1.2
~> echo $LD_LIBRARY_PATH

~> echo $CC

~> echo $CXX

~> echo SAGE_FORTRAN
SAGE_FORTRAN
~> echo $SAGE_FORTRAN

~> echo $SAGE_FORTRAN_LIB



Thanks!

Matthew

On May 26, 2:54 pm, David Kirkby  wrote:
> On 26 May 2010 11:57, Matthew Gwynne  wrote:
>
>
>
>
>
> > Hi,
>
> > The system information is given below -
>
> > 
> > Host system
> > uname -a:
> > Linux cs-wsok 2.6.13-15.8-smp #1 SMP Tue Feb 7 11:07:24 UTC 2006
> > x86_64 x86_64 x86_64 GNU/Linux
> > 
> > 
> > CC Version
> > gcc -v
> > Using built-in specs.
> > Target: x86_64-unknown-linux-gnu
> > Configured with: ./configure --enable-languages=c,c++ --enable-
> > threads=posix --enable-shared
> > Thread model: posix
>
> Something is odd here. You need to have a compiler supporting Fortran,
> yet yours was compiled without Fortran support. I'm very surprised the
> 'prereq' script does not detect this, as it should check for a fortran
> compiler and confirm its the same version as the C and C++ compilers.
>
> So unless you have two installations of gcc, both of the same version,
> I don't know how you got this far.
>
> can you give me the outputs of
>
> $ command -v gcc
> $ command -v g++
> $ command -v gfortran
> $ gcc -v
> $ g++ -v
> $ gfortran -v
> $ echo $LD_LIBRARY_PATH
> $ echo $CC
> $ echo $CXX
> $ echo SAGE_FORTRAN
> $ echo SAGE_FORTRAN_LIB
>
> Specifying the compiler locations with CC and CXX does not work too well
>
> Dave

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Problems building Sage 4.4.1

[David Kirkby]

On 26 May 2010 11:57, Matthew Gwynne  wrote:
> Hi,
>
> The system information is given below -
>
> 
> Host system
> uname -a:
> Linux cs-wsok 2.6.13-15.8-smp #1 SMP Tue Feb 7 11:07:24 UTC 2006
> x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> CC Version
> gcc -v
> Using built-in specs.
> Target: x86_64-unknown-linux-gnu
> Configured with: ./configure --enable-languages=c,c++ --enable-
> threads=posix --enable-shared
> Thread model: posix

Something is odd here. You need to have a compiler supporting Fortran,
yet yours was compiled without Fortran support. I'm very surprised the
'prereq' script does not detect this, as it should check for a fortran
compiler and confirm its the same version as the C and C++ compilers.

So unless you have two installations of gcc, both of the same version,
I don't know how you got this far.

can you give me the outputs of

$ command -v gcc
$ command -v g++
$ command -v gfortran
$ gcc -v
$ g++ -v
$ gfortran -v
$ echo $LD_LIBRARY_PATH
$ echo $CC
$ echo $CXX
$ echo SAGE_FORTRAN
$ echo SAGE_FORTRAN_LIB

Specifying the compiler locations with CC and CXX does not work too well

Dave

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Problems building Sage 4.4.1

[Matthew Gwynne]

Hi,

The system information is given below -


Host system
uname -a:
Linux cs-wsok 2.6.13-15.8-smp #1 SMP Tue Feb 7 11:07:24 UTC 2006
x86_64 x86_64 x86_64 GNU/Linux


CC Version
gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --enable-
threads=posix --enable-shared
Thread model: posix
gcc version 4.1.2

My colleague suggest that typically these errors are caused by missing
"-fPIC" options when building (or something
else must have gone wrong when building the libfpplll library).

Thanks!

Matthew


On May 24, 2:14 pm, kcrisman  wrote:
> On May 24, 9:11 am, kcrisman  wrote:
>
>
>
>
>
> > Dear Matthew,
>
> > Thanks for your report.  I know I can't answer your question fully :)
> > but I can say that the most likely way to receive more specific info
> > is to also post your OS, chip type if known, and any other info.
>
> > One reason I say this might be relevant is the following I found doing
> > a quick Google search for your error message, 
> > athttp://ugweb.cs.ualberta.ca/~rod/tutorials/error_messagesC.html:
>
> > " If you compile part of a
> > project on one type of architecture and then try to compile the rest
> > of the
> > project on another type of architecture, when you go to make the final
> > executable the linker/loader will NOT be able to read one of the parts
> > of the
> > project .o files to create an executable, thus the
> > "could not read symbols: File in wrong format" error message."
>
> > I'm not saying that's what the problem is, but information about your
> > physical computer and its system will help enormously in tracking this
> > down, especially if others have also experienced it.
>
> One more possible piece of useful info - any 32 versus 64 bit info you
> may have.
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to 
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group athttp://groups.google.com/group/sage-devel
> URL:http://www.sagemath.org

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Problems building Sage 4.4.1

[leif]

On 25 Mai, 11:18, leif  wrote:
> What I wanted to say is that installing another version of gcc in /usr/
> local on systems (like Linux distros) where there already is a
> "native" one (gcc) in /usr is non-trivial, i.e. this doesn't work "out
> of the box".
>
> With the "native" gcc, "-lstdc++" is passed to the linker (which would
> have worked in Matthew's installation, too), while with gcc in /usr/
> local its absolute filename is passed.

Oops, the "custom" gcc is actually installed in /usr, not /usr/local,
but this shouldn't matter... ;-)
(It is configured with "--enable-version-specific-runtime-libs" and "--
program-suffix=...".)

-Leif

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Problems building Sage 4.4.1

[leif]

On 25 Mai, 02:13, "Dr. David Kirkby"  wrote:
> On 05/24/10 05:26 PM, leif wrote:
>
> > Looks like the (fairly old) gcc/g++ in /usr/local is misconfigured; it
> > definitely tries to link a 64-bit (x86_64) C++ program against the 32-
> > bit libstdc++.so (in /usr/local/lib) instead of the 64-bit version in /
> > usr/local/lib64. (Actually it is forced to do so by libtool.)
>
> I'm not so convinced this failure with 'libfplll' is a gcc problem, but rather
> it is a 'libfplll' problem.
>
> I'm seeing the exact same issue with 'libfplll' on OpenSolaris.
>
> http://trac.sagemath.org/sage_trac/ticket/7864
>
> The fact the original poster, his colleague and myself are all seeing this,
> suggests to me that perhaps libfplll may be at fault in trying to link 64-bit
> objects to 32-bit libstdc++
>
> Other parts of the Sage build process are correctly using the 64-bit version 
> of
> libstdc++.so on my OpenSolaris box - see for example this line.

What I wanted to say is that installing another version of gcc in /usr/
local on systems (like Linux distros) where there already is a
"native" one (gcc) in /usr is non-trivial, i.e. this doesn't work "out
of the box".

With the "native" gcc, "-lstdc++" is passed to the linker (which would
have worked in Matthew's installation, too), while with gcc in /usr/
local its absolute filename is passed.

These are snippets from install.log, the first is from Sage 4.4.2 on
Ubuntu 9.04 x86_64 with "native" gcc (4.3.3), the second is from Sage
4.4.2.rc0 on Ubuntu 9.04 x86_64 with gcc 4.5.0 in /usr/local:

* "native" gcc in /usr:
-8<--8<--8<--8<--8<--8<--
 g++ -DPACKAGE_NAME=\"libfplll\" -DPACKAGE_TARNAME=\"libfplll\" -
DPACKAGE_VERSION=\"3.0.12\" "-DPACKAGE_STRING=\"libfplll 3.0.12\"" -
DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"libfplll\" -DVERSION=\"3.0.12\" -
DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -
DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -
DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -
DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBGMP=1 -DHAVE_LIBMPFR=1 -
DSTDC_HEADERS=1 -DHAVE_FLOAT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1 -
DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDBOOL_H=1 -DHAVE_FLOOR=1
-DHAVE_POW=1 -DHAVE_RINT=1 -DHAVE_SQRT=1 -DHAVE_STRTOL=1 -
DHAVE_LIBGMP=1 -DHAVE_LIBMPFR=1 -I. -I. -I/home/leif64/Sage/sage-4.4.2-
too/local/include/ -fPIC -I/home/leif64/Sage/sage-4.4.2-too/local/
include/ -L/home/leif64/Sage/sage-4.4.2-too/local/lib -MT dummy.lo -MD
-MP -MF .deps/dummy.Tpo -c dummy.cpp  -fPIC -DPIC -o .libs/dummy.o
 g++ -DPACKAGE_NAME=\"libfplll\" -DPACKAGE_TARNAME=\"libfplll\" -
DPACKAGE_VERSION=\"3.0.12\" "-DPACKAGE_STRING=\"libfplll 3.0.12\"" -
DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"libfplll\" -DVERSION=\"3.0.12\" -
DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -
DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -
DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -
DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBGMP=1 -DHAVE_LIBMPFR=1 -
DSTDC_HEADERS=1 -DHAVE_FLOAT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1 -
DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDBOOL_H=1 -DHAVE_FLOOR=1
-DHAVE_POW=1 -DHAVE_RINT=1 -DHAVE_SQRT=1 -DHAVE_STRTOL=1 -
DHAVE_LIBGMP=1 -DHAVE_LIBMPFR=1 -I. -I. -I/home/leif64/Sage/sage-4.4.2-
too/local/include/ -fPIC -I/home/leif64/Sage/sage-4.4.2-too/local/
include/ -L/home/leif64/Sage/sage-4.4.2-too/local/lib -MT dummy.lo -MD
-MP -MF .deps/dummy.Tpo -c dummy.cpp -o dummy.o >/dev/null 2>&1
/bin/bash ./libtool --tag=CXX --mode=link g++  -fPIC -I/home/leif64/
Sage/sage-4.4.2-too/local/include/ -L/home/leif64/Sage/sage-4.4.2-too/
local/lib   -o libfplll.la -rpath /home/leif64/Sage/sage-4.4.2-too/
local/lib -version-info 1:0:1 dummy.lo -lgmp -lmpfr -lmpfr -lgmp -
lmpfr -lgmp
g++ -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../
lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.3.3/crtbeginS.o  .libs/
dummy.o  -Wl,--rpath -Wl,/home/leif64/Sage/sage-4.4.2-too/local/lib -
Wl,--rpath -Wl,/home/leif64/Sage/sage-4.4.2-too/local/lib -L/home/
leif64/Sage/sage-4.4.2-too/local/lib /home/leif64/Sage/sage-4.4.2-too/
local/lib/libmpfr.so /home/leif64/Sage/sage-4.4.2-too/local/lib/
libgmp.so -L/home/leif64/Sage/sage-4.4.2-too/local/lib/../lib -L/usr/
lib/gcc/x86_64-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-linux-gnu/
4.3.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/
x86_64-linux-gnu/4.3.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/
x86_64-linux-gnu/4.3.3/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/
4.3.3/../../../../lib/crtn.o  -Wl,-soname -Wl,libfplll.so.0 -o .libs/
libfplll.so.0.1.0
(cd .libs && rm -f libfplll.so.0 && ln -s libfplll.so.0.1.0
libfplll.so.0)
(cd .libs && rm -f libfplll.so && ln -s libfplll.so.0.1.0 libfplll.so)
ar cru .libs/libfplll.a  dummy.o
ranlib .libs/libfplll.a
creating libfplll.la
(cd .libs && rm -f libfplll.la && ln -s ../libfplll.la libfplll.la)
make[3]: Verlasse Verzeichnis '/home/leif64/Sage/sage-4.4.2-too/spkg/
build/libfpl

Re: [sage-devel] Re: Problems building Sage 4.4.1

[Dr. David Kirkby]

On 05/24/10 05:26 PM, leif wrote:

On 24 Mai, 14:45, Matthew Gwynne  wrote:

When building Sage 4.4.1, I (and also my colleague) get the following
errors during the build process -

/bin/sh ./libtool --tag=CXX --mode=link g++  -fPIC -I/home/csoliver/
SAT-Algorithmen/OKplatform/ExternalSources/Installations/Sage/
sage-4.4.1/local/include/ -L/home/csoliver/SAT-Algorithmen/OKplatform/
ExternalSources/Installations/Sage/sage-4.4.1/local/lib   -o
libfplll.la -rpath /home/csoliver/SAT-Algorithmen/OKplatform/
ExternalSources/Installations/Sage/sage-4.4.1/local/lib -version-info
1:0:1 dummy.lo -lgmp -lmpfr -lmpfr -lgmp -lmpfr -lgmp
g++ -shared -nostdlib /usr/lib/../lib64/crti.o /usr/local/lib/gcc/
x86_64-unknown-linux-gnu/4.1.2/crtbeginS.o  .libs/dummy.o  -Wl,--rpath
-Wl,/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/
Installations/Sage/sage-4.4.1/local/lib -Wl,--rpath -Wl,/usr/local/
lib/../lib -Wl,--rpath -Wl,/home/csoliver/SAT-Algorithmen/OKplatform/
ExternalSources/Installations/Sage/sage-4.4.1/local/lib -Wl,--rpath -
Wl,/usr/local/lib/../lib -L/home/csoliver/SAT-Algorithmen/OKplatform/
ExternalSources/Installations/Sage/sage-4.4.1/local/lib /home/csoliver/
SAT-Algorithmen/OKplatform/ExternalSources/Installations/Sage/
sage-4.4.1/local/lib/libmpfr.so /home/csoliver/SAT-Algorithmen/
OKplatform/ExternalSources/Installations/Sage/sage-4.4.1/local/lib/
libgmp.so -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.1.2 -L/usr/
local/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../x86_64-
unknown-linux-gnu/lib -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/
4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 /usr/local/
lib/../lib/libstdc++.so -lm -lc -lgcc_s /usr/local/lib/gcc/x86_64-
unknown-linux-gnu/4.1.2/crtendS.o /usr/lib/../lib64/crtn.o  -Wl,-
soname -Wl,libfplll.so.0 -o .libs/libfplll.so.0.1.0
/usr/local/lib/../lib/libstdc++.so: could not read symbols: File in
wrong format
collect2: ld returned 1 exit status
make[4]: *** [libfplll.la] Error 1
make[4]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/
ExternalSources/Installations/Sage/sage-4.4.1/spkg/build/
libfplll-3.0.12.p0/src'

Does anyone have any idea if I am doing something wrong, or whether
this is a possible problem with Sage itself?


Looks like the (fairly old) gcc/g++ in /usr/local is misconfigured; it
definitely tries to link a 64-bit (x86_64) C++ program against the 32-
bit libstdc++.so (in /usr/local/lib) instead of the 64-bit version in /
usr/local/lib64. (Actually it is forced to do so by libtool.)

-Leif



I'm not so convinced this failure with 'libfplll' is a gcc problem, but rather 
it is a 'libfplll' problem.


I'm seeing the exact same issue with 'libfplll' on OpenSolaris.

http://trac.sagemath.org/sage_trac/ticket/7864

The fact the original poster, his colleague and myself are all seeing this, 
suggests to me that perhaps libfplll may be at fault in trying to link 64-bit 
objects to 32-bit libstdc++


Other parts of the Sage build process are correctly using the 64-bit version of 
libstdc++.so on my OpenSolaris box - see for example this line.


g++ -shared -nostdlib  /usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o 
/usr/local/gcc-4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/amd64/crtbegin.o 
.libs/dummy.o cxx/.libs/isfuns.o cxx/.libs/ismpf.o cxx/.libs/ismpq.o 
cxx/.libs/ismpz.o cxx/.libs/ismpznw.o cxx/.libs/osdoprnti.o cxx/.libs/osfuns.o 
cxx/.libs/osmpf.o cxx/.libs/osmpq.o cxx/.libs/osmpz.o  -Wl,-R 
-Wl,/export/home/drkirkby/sage-4.4.2/spkg/build/mpir-1.2.2.p1/src/.libs -Wl,-R 
-Wl,/usr/local/gcc-4.4.4/lib/amd64 -Wl,-R 
-Wl,/export/home/drkirkby/sage-4.4.2/local/lib -Wl,-R 
-Wl,/usr/local/gcc-4.4.4/lib/amd64 ./.libs/libgmp.so 
-L/usr/local/gcc-4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/amd64 
-L/usr/local/gcc-4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/../../../amd64 
-L/lib/amd64 -L/usr/lib/amd64 -L/export/home/drkirkby/sage-4.4.2/local/lib 
-L/usr/local/gcc-4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4 
-L/usr/local/gcc-4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/../../.. 
/usr/local/gcc-4.4.4/lib/amd64/libstdc++.so -lm -lgcc_s 
/usr/local/gcc-4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/amd64/crtend.o 
/usr/lib/amd64/crtn.o  -m64 -march=core2 -mtune=core2 -Wl,-h -Wl,libgmpxx.so.3 
-o .libs/libgmpxx.so.3.1.6


where you can see that the 64-bit /usr/local/gcc-4.4.4/lib/amd64/libstdc++.so 
library is used, not the 32-bit library at /usr/local/gcc-4.4.4/lib/libstdc++.so


So some parts of the Sage build process manage to work out that the 64-bit 
library should be used, but libfplll does not.


I've found a similar issue with pynac. It would be intersting what the original 
poster gets if he runs:


$ ./sage -f pynac-0.1.12 (or it might need to be)
$ ./sage -f pynac-0.1.11

I would not be surprised if he sees the same problem.

Dave


--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at

[sage-devel] Re: Problems building Sage 4.4.1

[leif]

On 24 Mai, 14:45, Matthew Gwynne  wrote:
> When building Sage 4.4.1, I (and also my colleague) get the following
> errors during the build process -
>
> /bin/sh ./libtool --tag=CXX --mode=link g++  -fPIC -I/home/csoliver/
> SAT-Algorithmen/OKplatform/ExternalSources/Installations/Sage/
> sage-4.4.1/local/include/ -L/home/csoliver/SAT-Algorithmen/OKplatform/
> ExternalSources/Installations/Sage/sage-4.4.1/local/lib   -o
> libfplll.la -rpath /home/csoliver/SAT-Algorithmen/OKplatform/
> ExternalSources/Installations/Sage/sage-4.4.1/local/lib -version-info
> 1:0:1 dummy.lo -lgmp -lmpfr -lmpfr -lgmp -lmpfr -lgmp
> g++ -shared -nostdlib /usr/lib/../lib64/crti.o /usr/local/lib/gcc/
> x86_64-unknown-linux-gnu/4.1.2/crtbeginS.o  .libs/dummy.o  -Wl,--rpath
> -Wl,/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/
> Installations/Sage/sage-4.4.1/local/lib -Wl,--rpath -Wl,/usr/local/
> lib/../lib -Wl,--rpath -Wl,/home/csoliver/SAT-Algorithmen/OKplatform/
> ExternalSources/Installations/Sage/sage-4.4.1/local/lib -Wl,--rpath -
> Wl,/usr/local/lib/../lib -L/home/csoliver/SAT-Algorithmen/OKplatform/
> ExternalSources/Installations/Sage/sage-4.4.1/local/lib /home/csoliver/
> SAT-Algorithmen/OKplatform/ExternalSources/Installations/Sage/
> sage-4.4.1/local/lib/libmpfr.so /home/csoliver/SAT-Algorithmen/
> OKplatform/ExternalSources/Installations/Sage/sage-4.4.1/local/lib/
> libgmp.so -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.1.2 -L/usr/
> local/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../x86_64-
> unknown-linux-gnu/lib -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/
> 4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 /usr/local/
> lib/../lib/libstdc++.so -lm -lc -lgcc_s /usr/local/lib/gcc/x86_64-
> unknown-linux-gnu/4.1.2/crtendS.o /usr/lib/../lib64/crtn.o  -Wl,-
> soname -Wl,libfplll.so.0 -o .libs/libfplll.so.0.1.0
> /usr/local/lib/../lib/libstdc++.so: could not read symbols: File in
> wrong format
> collect2: ld returned 1 exit status
> make[4]: *** [libfplll.la] Error 1
> make[4]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/
> ExternalSources/Installations/Sage/sage-4.4.1/spkg/build/
> libfplll-3.0.12.p0/src'
>
> Does anyone have any idea if I am doing something wrong, or whether
> this is a possible problem with Sage itself?

Looks like the (fairly old) gcc/g++ in /usr/local is misconfigured; it
definitely tries to link a 64-bit (x86_64) C++ program against the 32-
bit libstdc++.so (in /usr/local/lib) instead of the 64-bit version in /
usr/local/lib64. (Actually it is forced to do so by libtool.)

-Leif

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Problems building Sage 4.4.1

[kcrisman]

On May 24, 9:11 am, kcrisman  wrote:
> Dear Matthew,
>
> Thanks for your report.  I know I can't answer your question fully :)
> but I can say that the most likely way to receive more specific info
> is to also post your OS, chip type if known, and any other info.
>
> One reason I say this might be relevant is the following I found doing
> a quick Google search for your error message, 
> athttp://ugweb.cs.ualberta.ca/~rod/tutorials/error_messagesC.html:
>
> " If you compile part of a
> project on one type of architecture and then try to compile the rest
> of the
> project on another type of architecture, when you go to make the final
> executable the linker/loader will NOT be able to read one of the parts
> of the
> project .o files to create an executable, thus the
> "could not read symbols: File in wrong format" error message."
>
> I'm not saying that's what the problem is, but information about your
> physical computer and its system will help enormously in tracking this
> down, especially if others have also experienced it.
>

One more possible piece of useful info - any 32 versus 64 bit info you
may have.

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Problems building Sage 4.4.1

[kcrisman]

Dear Matthew,

Thanks for your report.  I know I can't answer your question fully :)
but I can say that the most likely way to receive more specific info
is to also post your OS, chip type if known, and any other info.

One reason I say this might be relevant is the following I found doing
a quick Google search for your error message, at
http://ugweb.cs.ualberta.ca/~rod/tutorials/error_messagesC.html :

" If you compile part of a
project on one type of architecture and then try to compile the rest
of the
project on another type of architecture, when you go to make the final
executable the linker/loader will NOT be able to read one of the parts
of the
project .o files to create an executable, thus the
"could not read symbols: File in wrong format" error message."

I'm not saying that's what the problem is, but information about your
physical computer and its system will help enormously in tracking this
down, especially if others have also experienced it.

Best,
- kcrisman

On May 24, 8:45 am, Matthew Gwynne  wrote:
> Hi,
>
> When building Sage 4.4.1, I (and also my colleague) get the following
> errors during the build process -
>
> /bin/sh ./libtool --tag=CXX --mode=link g++  -fPIC -I/home/csoliver/
> SAT-Algorithmen/OKplatform/ExternalSources/Installations/Sage/
> sage-4.4.1/local/include/ -L/home/csoliver/SAT-Algorithmen/OKplatform/
> ExternalSources/Installations/Sage/sage-4.4.1/local/lib   -o
> libfplll.la -rpath /home/csoliver/SAT-Algorithmen/OKplatform/
> ExternalSources/Installations/Sage/sage-4.4.1/local/lib -version-info
> 1:0:1 dummy.lo -lgmp -lmpfr -lmpfr -lgmp -lmpfr -lgmp
> g++ -shared -nostdlib /usr/lib/../lib64/crti.o /usr/local/lib/gcc/
> x86_64-unknown-linux-gnu/4.1.2/crtbeginS.o  .libs/dummy.o  -Wl,--rpath
> -Wl,/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/
> Installations/Sage/sage-4.4.1/local/lib -Wl,--rpath -Wl,/usr/local/
> lib/../lib -Wl,--rpath -Wl,/home/csoliver/SAT-Algorithmen/OKplatform/
> ExternalSources/Installations/Sage/sage-4.4.1/local/lib -Wl,--rpath -
> Wl,/usr/local/lib/../lib -L/home/csoliver/SAT-Algorithmen/OKplatform/
> ExternalSources/Installations/Sage/sage-4.4.1/local/lib /home/csoliver/
> SAT-Algorithmen/OKplatform/ExternalSources/Installations/Sage/
> sage-4.4.1/local/lib/libmpfr.so /home/csoliver/SAT-Algorithmen/
> OKplatform/ExternalSources/Installations/Sage/sage-4.4.1/local/lib/
> libgmp.so -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.1.2 -L/usr/
> local/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../x86_64-
> unknown-linux-gnu/lib -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/
> 4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 /usr/local/
> lib/../lib/libstdc++.so -lm -lc -lgcc_s /usr/local/lib/gcc/x86_64-
> unknown-linux-gnu/4.1.2/crtendS.o /usr/lib/../lib64/crtn.o  -Wl,-
> soname -Wl,libfplll.so.0 -o .libs/libfplll.so.0.1.0
> /usr/local/lib/../lib/libstdc++.so: could not read symbols: File in
> wrong format
> collect2: ld returned 1 exit status
> make[4]: *** [libfplll.la] Error 1
> make[4]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/
> ExternalSources/Installations/Sage/sage-4.4.1/spkg/build/
> libfplll-3.0.12.p0/src'
>
> Does anyone have any idea if I am doing something wrong, or whether
> this is a possible problem with Sage itself?
>
> Thanks!
>
> Matthew
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to 
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group athttp://groups.google.com/group/sage-devel
> URL:http://www.sagemath.org

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Problems building Sage 3.0.2 on Solaris 10 - NTL issue

[Dr. David Kirkby]

On Jun 5, 12:36 am, Francois <[EMAIL PROTECTED]> wrote:

> Spot on Michael. gcc config is given at the beginning of the
> compilation and says: --without-gnu-ld --with-ld=/usr/ccs/bin/ld
>
> OK back to square one to put together a better patch.
> It's at time like this that you start wishing everything was
> auto/lib-tooled.
>
> Cheers,
> Francois

Feel free to log in and test your patch.


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Problems building Sage 3.0.2 on Solaris 10 - NTL issue

[Dr. David Kirkby]

On Jun 5, 12:05 am, mabshoff <[EMAIL PROTECTED]> wrote:

> > g++ -I../include -I.  -O2 -g  -fPIC  -fPIC -shared -Wl,-soname,lib`cat
> > DIRNAME`.so -o lib`cat DIRNAME`.so FFT.o FacVec.o GF2.o GF2E.o GF2EX.o
> > GF2EXFactoring.o GF2X.o GF2X1.o GF2XFactoring.o GF2XVec.o GetTime.o
> > HNF.o ctools.o LLL.o LLL_FP.o LLL_QP.o LLL_RR.o LLL_XD.o RR.o
> > WordVector.o ZZ.o ZZVec.o ZZX.o ZZX1.o ZZXCharPoly.o ZZXFactoring.o
> > ZZ_p.o ZZ_pE.o ZZ_pEX.o ZZ_pEXFactoring.o ZZ_pX.o ZZ_pX1.o
> > ZZ_pXCharPoly.o ZZ_pXFactoring.o fileio.o lip.o lzz_p.o lzz_pE.o
> > lzz_pEX.o lzz_pEXFactoring.o lzz_pX.o lzz_pX1.o lzz_pXCharPoly.o
> > lzz_pXFactoring.o mat_GF2.o mat_GF2E.o mat_RR.o mat_ZZ.o mat_ZZ_p.o
> > mat_ZZ_pE.o mat_lzz_p.o mat_lzz_pE.o mat_poly_ZZ.o mat_poly_ZZ_p.o
> > mat_poly_lzz_p.o pair_GF2EX_long.o pair_GF2X_long.o pair_ZZX_long.o
> > pair_ZZ_pEX_long.o pair_ZZ_pX_long.o pair_lzz_pEX_long.o
> > pair_lzz_pX_long.o quad_float.o tools.o vec_GF2.o vec_GF2E.o
> > vec_GF2XVec.o vec_RR.o vec_ZZ.o vec_ZZVec.o vec_ZZ_p.o vec_ZZ_pE.o
> > vec_double.o vec_long.o vec_lzz_p.o vec_lzz_pE.o vec_quad_float.o
> > vec_vec_GF2.o vec_vec_GF2E.o vec_vec_RR.o vec_vec_ZZ.o vec_vec_ZZ_p.o
> > vec_vec_ZZ_pE.o vec_vec_long.o vec_vec_lzz_p.o vec_vec_lzz_pE.o
> > vec_xdouble.o xdouble.o G_LLL_FP.o G_LLL_QP.o G_LLL_XD.o G_LLL_RR.o
> > vec_ulong.o vec_vec_ulong.o -L/export/home/drkirkby/sage-3.0.2/local/
> > lib -lgmp
> > ld: warning: option -o appears more than once, first setting taken
> > ld: fatal: file libntl-5.4.2.so: unknown file type
> > ld: fatal: File processing errors. No output written to
>
> This rings a bell: Any chance your gcc was build using the Sun ld and
> not the GNU ld? I would change
>
>  -Wl,-soname,lib`cat  DIRNAME`.so -o lib`cat DIRNAME`.so
>
> to
>
>  -o libntl.so
>
> since the that does not work with the Sun ld IIRC.

Yes, it was built with Sun's linker, not GNU's. Both Sunfeeware and
Blastwave build it with that, and it's generally reckoned to work
better than with the GNU linker.

Hence it would be prefereable if you could avoid the GNU isms here.

It's 1:35 am here, and time I sent to bed, so I am not going to look
at this any more - time for bed. I doubt I'll get much chance tommorow
later today either, as I am going out for the day and night. (But will
have access via ssh during the day).

I've set up another Sun (dual processor U;tra 60) and have emailed
Francois some login details.

> By now I am
> actually thinking that we should not add "-Kl,-soname $FOO" & friends
> to the default makefiles since those are GNU ld specific.

GNU isms are the pain in the life of Solaris users!!!


Dave
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Problems building Sage 3.0.2 on Solaris 10 - NTL issue

[Francois]

On Jun 5, 11:05 am, mabshoff <[EMAIL PROTECTED]> wrote:
> On Jun 5, 12:56 am, "Dr. David Kirkby" <[EMAIL PROTECTED]>
> wrote:
>
> > On Jun 4, 8:35 pm, mabshoff <[EMAIL PROTECTED]> wrote:
>
> 
>
> Hi David,
>
> > I don't believe the problem I was experiencing is anything to do with
> > the shell, or how it is called. As Is said, I'm not using csh or tcsh
> > as a login shell, but bash.
>
> Ok, but that bug also exists ;)
>

I am sure it does :)


> > ld: warning: option -o appears more than once, first setting taken
> > ld: fatal: file libntl-5.4.2.so: unknown file type
> > ld: fatal: File processing errors. No output written to
>
> This rings a bell: Any chance your gcc was build using the Sun ld and
> not the GNU ld? I would change
>
>  -Wl,-soname,lib`cat  DIRNAME`.so -o lib`cat DIRNAME`.so
>
> to
>
>  -o libntl.so
>
> since the that does not work with the Sun ld IIRC. By now I am
> actually thinking that we should not add "-Kl,-soname $FOO" & friends
> to the default makefiles since those are GNU ld specific.
>
Spot on Michael. gcc config is given at the beginning of the
compilation and says: --without-gnu-ld --with-ld=/usr/ccs/bin/ld

OK back to square one to put together a better patch.
It's at time like this that you start wishing everything was
auto/lib-tooled.

Cheers,
Francois

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Problems building Sage 3.0.2 on Solaris 10 - NTL issue

[mabshoff]

On Jun 5, 12:56 am, "Dr. David Kirkby" <[EMAIL PROTECTED]>
wrote:
> On Jun 4, 8:35 pm, mabshoff <[EMAIL PROTECTED]> wrote:



Hi David,

> I don't believe the problem I was experiencing is anything to do with
> the shell, or how it is called. As Is said, I'm not using csh or tcsh
> as a login shell, but bash.

Ok, but that bug also exists ;)

> I believe Francois is much closer to the solution myself. I took out
> the test for SunOs, so do_make setup1, do_make setup2, do_make setup3
> and do_make setup4 were all run. i.e. I changed the do_tune() code to:
>
> do_tune()
> {
>     do_make setup1
>     do_make setup2
>     do_make setup3
>     do_make setup4
>
> }
>
> That works a LOT better, but it still fails to build, but that is a
> different issue. So I'm not convinced there is a need to exclude the
> setup routines on Solaris - whether they are useful or a waste of time
> is another matter, but they don't stop it building.
>
> I can't make any sence of the what is causing this to fail. The error
> message from the compiler says the -o option is given twice (which it
> is not)! It then says it does not know the file type for
> libntl-5.4.2.so. It seems to me the options to the compiler look
> sensible, so I don't understand its objection. It could be a compiler
> bug.
>
> Would anyone be in a better position to fix this if I made a Solaris
> (SPARC) machine available? This is my private machine and I don't wish
> to share it, but if it will be any help I could set up another SPARC
> with similar software on it.
>
> Dave



> g++ -I../include -I.  -O2 -g  -fPIC  -fPIC -shared -Wl,-soname,lib`cat
> DIRNAME`.so -o lib`cat DIRNAME`.so FFT.o FacVec.o GF2.o GF2E.o GF2EX.o
> GF2EXFactoring.o GF2X.o GF2X1.o GF2XFactoring.o GF2XVec.o GetTime.o
> HNF.o ctools.o LLL.o LLL_FP.o LLL_QP.o LLL_RR.o LLL_XD.o RR.o
> WordVector.o ZZ.o ZZVec.o ZZX.o ZZX1.o ZZXCharPoly.o ZZXFactoring.o
> ZZ_p.o ZZ_pE.o ZZ_pEX.o ZZ_pEXFactoring.o ZZ_pX.o ZZ_pX1.o
> ZZ_pXCharPoly.o ZZ_pXFactoring.o fileio.o lip.o lzz_p.o lzz_pE.o
> lzz_pEX.o lzz_pEXFactoring.o lzz_pX.o lzz_pX1.o lzz_pXCharPoly.o
> lzz_pXFactoring.o mat_GF2.o mat_GF2E.o mat_RR.o mat_ZZ.o mat_ZZ_p.o
> mat_ZZ_pE.o mat_lzz_p.o mat_lzz_pE.o mat_poly_ZZ.o mat_poly_ZZ_p.o
> mat_poly_lzz_p.o pair_GF2EX_long.o pair_GF2X_long.o pair_ZZX_long.o
> pair_ZZ_pEX_long.o pair_ZZ_pX_long.o pair_lzz_pEX_long.o
> pair_lzz_pX_long.o quad_float.o tools.o vec_GF2.o vec_GF2E.o
> vec_GF2XVec.o vec_RR.o vec_ZZ.o vec_ZZVec.o vec_ZZ_p.o vec_ZZ_pE.o
> vec_double.o vec_long.o vec_lzz_p.o vec_lzz_pE.o vec_quad_float.o
> vec_vec_GF2.o vec_vec_GF2E.o vec_vec_RR.o vec_vec_ZZ.o vec_vec_ZZ_p.o
> vec_vec_ZZ_pE.o vec_vec_long.o vec_vec_lzz_p.o vec_vec_lzz_pE.o
> vec_xdouble.o xdouble.o G_LLL_FP.o G_LLL_QP.o G_LLL_XD.o G_LLL_RR.o
> vec_ulong.o vec_vec_ulong.o -L/export/home/drkirkby/sage-3.0.2/local/
> lib -lgmp
> ld: warning: option -o appears more than once, first setting taken
> ld: fatal: file libntl-5.4.2.so: unknown file type
> ld: fatal: File processing errors. No output written to

This rings a bell: Any chance your gcc was build using the Sun ld and
not the GNU ld? I would change

 -Wl,-soname,lib`cat  DIRNAME`.so -o lib`cat DIRNAME`.so

to

 -o libntl.so

since the that does not work with the Sun ld IIRC. By now I am
actually thinking that we should not add "-Kl,-soname $FOO" & friends
to the default makefiles since those are GNU ld specific.



Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Problems building Sage 3.0.2 on Solaris 10 - NTL issue

[Dr. David Kirkby]

On Jun 4, 8:35 pm, mabshoff <[EMAIL PROTECTED]> wrote:
> On Jun 4, 9:30 pm, Francois <[EMAIL PROTECTED]> wrote:
>
> > On Jun 5, 1:10 am, mabshoff <[EMAIL PROTECTED]> wrote:
>
> 
>
> > > gmp_aux.h exists without the tuning, but I am not sure why we skip the
> > > tuning on Solaris. I will certainly see if I cannot reactivate that.
> > > As I mentioned in the other email when you use a csh as login shell
> > > the current build does not work. I believe it is due to some scripts
> > > being called from the makefile as
>
> > >   sh foo
>
> > > while foo does not have a shebang. Then things seem to also go bad on
> > > Linux for example, so this is not a Solaris specific problem, but
> > > shell related. I have build the NTL.spkg numerous times on Solaris
> > > with either a sh or bash login shell, so it does work some times ;)
>
> Hi Francois,
>
> > Could be a contributin factor.
>
> Probably since I have had it reported to me off list on a Linux box.
>
> > However before the mfile patch from
> > Tim and I, the call to "make lib" was calling "make setup1" to "make
> > setup3"
> > a behavior we didn't reproduce in our target. So if you have an older
> > sage
> > setup3 would be called anyway but not in a recent one.
> > I also checked the spkg (and the upstream tarball) gmp_aux.h is
> > definitely not there.
> > Technically the tunning is setup4 so yes it would exist without the
> > tunning :)
> > In retrospect we should probably should have included some
> > of those make setup calls in our patch.
>
> I am 100% certain that the NTL.spkg as is can be build on Solaris
> because I have build this spkg and its predecessors dozens of times on
> Solaris 9 and 10 in all kinds of configurations. Obviously there is a
> bug or two in here, but it isn't the setup routines that are at fault
> here.
>
> > Francois
>
> Cheers,
>
> Michael


I don't believe the problem I was experiencing is anything to do with
the shell, or how it is called. As Is said, I'm not using csh or tcsh
as a login shell, but bash.

I believe Francois is much closer to the solution myself. I took out
the test for SunOs, so do_make setup1, do_make setup2, do_make setup3
and do_make setup4 were all run. i.e. I changed the do_tune() code to:



do_tune()
{
do_make setup1
do_make setup2
do_make setup3
do_make setup4
}

That works a LOT better, but it still fails to build, but that is a
different issue. So I'm not convinced there is a need to exclude the
setup routines on Solaris - whether they are useful or a waste of time
is another matter, but they don't stop it building.

I can't make any sence of the what is causing this to fail. The error
message from the compiler says the -o option is given twice (which it
is not)! It then says it does not know the file type for
libntl-5.4.2.so. It seems to me the options to the compiler look
sensible, so I don't understand its objection. It could be a compiler
bug.

Would anyone be in a better position to fix this if I made a Solaris
(SPARC) machine available? This is my private machine and I don't wish
to share it, but if it will be any help I could set up another SPARC
with similar software on it.


Dave

[EMAIL PROTECTED]:[~/sage-3.0.2] $ make
cd spkg && ./install all 2>&1 | tee -a ../install.log
make[1]: Entering directory `/export/home/drkirkby/sage-3.0.2/spkg'
sage-spkg ntl-5.4.2.p3 2>&1
You must set the SAGE_ROOT environment variable or
run this script from the SAGE_ROOT or
SAGE_ROOT/local/bin/ directory.
ntl-5.4.2.p3
Machine:
SunOS kestrel 5.10 Generic_120011-14 sun4u sparc SUNW,Sun-Blade-1000
Deleting directories from past builds of previous/current versions of
ntl-5.4.2.p3
Extracting package /export/home/drkirkby/sage-3.0.2/spkg/standard/
ntl-5.4.2.p3.spkg ...
-rw-r--r--   1 drkirkby animals   573992 Jun  4 23:10 /export/home/
drkirkby/sage-3.0.2/spkg/standard/ntl-5.4.2.p3.spkg
x ntl-5.4.2.p3, 0 bytes, 0 tape blocks
x ntl-5.4.2.p3/.hgignore, 4 bytes, 1 tape blocks

x ntl-5.4.2.p3/src/src/DispSettings.c, 2197 bytes, 5 tape blocks
x ntl-5.4.2.p3/src/src/pair_lzz_pX_long.c, 386 bytes, 1 tape blocks
Finished extraction

Host system
uname -a:
SunOS kestrel 5.10 Generic_120011-14 sun4u sparc SUNW,Sun-Blade-1000


GCC Version
gcc -v
Reading specs from /usr/local/opt/csw/gcc4/bin/../lib/gcc/sparc-sun-
solaris2.8/4.0.2/specs
Target: sparc-sun-solaris2.8
Configured with: ../sources/gcc-4.0.2/configure --prefix=/opt/csw/gcc4
--with-local-prefix=/opt/csw --without-gnu-as --with-as=/usr/ccs/bin/
as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --
enable-shared --enable-multilib --enable-nls --with-included-gettext --
with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --with-
system-zlib --enable-languages=c,c++,f95,java,objc,ada
Thread model: posix
gcc version 4.0.2
*

[sage-devel] Re: Problems building Sage 3.0.2 on Solaris 10 - NTL issue

[mabshoff]

On Jun 4, 9:30 pm, Francois <[EMAIL PROTECTED]> wrote:
> On Jun 5, 1:10 am, mabshoff <[EMAIL PROTECTED]> wrote:



> > gmp_aux.h exists without the tuning, but I am not sure why we skip the
> > tuning on Solaris. I will certainly see if I cannot reactivate that.
> > As I mentioned in the other email when you use a csh as login shell
> > the current build does not work. I believe it is due to some scripts
> > being called from the makefile as
>
> >   sh foo
>
> > while foo does not have a shebang. Then things seem to also go bad on
> > Linux for example, so this is not a Solaris specific problem, but
> > shell related. I have build the NTL.spkg numerous times on Solaris
> > with either a sh or bash login shell, so it does work some times ;)

Hi Francois,

> Could be a contributin factor.

Probably since I have had it reported to me off list on a Linux box.

> However before the mfile patch from
> Tim and I, the call to "make lib" was calling "make setup1" to "make
> setup3"
> a behavior we didn't reproduce in our target. So if you have an older
> sage
> setup3 would be called anyway but not in a recent one.
> I also checked the spkg (and the upstream tarball) gmp_aux.h is
> definitely not there.
> Technically the tunning is setup4 so yes it would exist without the
> tunning :)
> In retrospect we should probably should have included some
> of those make setup calls in our patch.

I am 100% certain that the NTL.spkg as is can be build on Solaris
because I have build this spkg and its predecessors dozens of times on
Solaris 9 and 10 in all kinds of configurations. Obviously there is a
bug or two in here, but it isn't the setup routines that are at fault
here.

> Francois

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Problems building Sage 3.0.2 on Solaris 10 - NTL issue

[Francois]

On Jun 5, 1:10 am, mabshoff <[EMAIL PROTECTED]> wrote:
> On Jun 4, 2:56 pm, Francois <[EMAIL PROTECTED]> wrote:
> 
>
>
>
> > Hi,
>
> Hi Francois,
>
> > It looks like gmp_aux.h is generated during "make setup3" which is
> > completely skipped on sun, from the skpg-install script:
> > do_tune()
> > {
> > if [ $UNAME = "SunOS" ]; then
> > return
> > fi
> > do_make setup1
> > do_make setup2
> > do_make setup3
> > do_make setup4}
>
> > -
> > May be you could try to insert "do_make setup3" before ...
>
> gmp_aux.h exists without the tuning, but I am not sure why we skip the
> tuning on Solaris. I will certainly see if I cannot reactivate that.
> As I mentioned in the other email when you use a csh as login shell
> the current build does not work. I believe it is due to some scripts
> being called from the makefile as
>
>   sh foo
>
> while foo does not have a shebang. Then things seem to also go bad on
> Linux for example, so this is not a Solaris specific problem, but
> shell related. I have build the NTL.spkg numerous times on Solaris
> with either a sh or bash login shell, so it does work some times ;)
>
Could be a contributin factor. However before the mfile patch from
Tim and I, the call to "make lib" was calling "make setup1" to "make
setup3"
a behavior we didn't reproduce in our target. So if you have an older
sage
setup3 would be called anyway but not in a recent one.
I also checked the spkg (and the upstream tarball) gmp_aux.h is
definitely not there.
Technically the tunning is setup4 so yes it would exist without the
tunning :)
In retrospect we should probably should have included some
of those make setup calls in our patch.

Francois
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Problems building Sage 3.0.2 on Solaris 10 - NTL issue

[Dr. David Kirkby]

> Hi Dave,
>
> I know one issue with NTL that pops up when people use either csh or
> tcsh as a login shell and I got a likely fix that will be in Sage
> 3.0.3.
>
> 
>
> Cheers,
>
> Michael

It's not that

[EMAIL PROTECTED]:[~] $ grep drkirkby /etc/passwd
drkirkby:x:100:100::/export/home/drkirkby:/bin/bash

It looks more like the thing Francois said, although I have not
checked it.



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Problems building Sage 3.0.2 on Solaris 10 - NTL issue

[mabshoff]

On Jun 4, 2:56 pm, Francois <[EMAIL PROTECTED]> wrote:

>
> Hi,

Hi Francois,

> It looks like gmp_aux.h is generated during "make setup3" which is
> completely skipped on sun, from the skpg-install script:
> do_tune()
> {
>     if [ $UNAME = "SunOS" ]; then
>         return
>     fi
>     do_make setup1
>     do_make setup2
>     do_make setup3
>     do_make setup4}
>
> -
> May be you could try to insert "do_make setup3" before ...

gmp_aux.h exists without the tuning, but I am not sure why we skip the
tuning on Solaris. I will certainly see if I cannot reactivate that.
As I mentioned in the other email when you use a csh as login shell
the current build does not work. I believe it is due to some scripts
being called from the makefile as

  sh foo

while foo does not have a shebang. Then things seem to also go bad on
Linux for example, so this is not a Solaris specific problem, but
shell related. I have build the NTL.spkg numerous times on Solaris
with either a sh or bash login shell, so it does work some times ;)

> read more »

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Problems building Sage 3.0.2 on Solaris 10 - NTL issue

[mabshoff]

On Jun 4, 2:06 pm, "Dr. David Kirkby" <[EMAIL PROTECTED]> wrote:
> Here's my attempt to build sage 3.0.2 on Solaris (SPARC).
>
> The build process reports gmp_aux.h is not found, I checked and there
> is no such file. However, this in itself does not cause the build
> process to stop, but it later stops when various things are
> undefined.
>
> See below.
>
> The system in a Sun Blade 2000 running Solaris 10 update 4. gcc 4.0.2
> from Blastwave, and gnu make.
>
> I noticed gmp_aux.h exists in Singlular I have on the disk, but I'm
> not sure if that is the correct version. In any case, it needs
> fixing.
>
> Dave

Hi Dave,

I know one issue with NTL that pops up when people use either csh or
tcsh as a login shell and I got a likely fix that will be in Sage
3.0.3.



Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Problems building Sage 3.0.2 on Solaris 10 - NTL issue

[Francois]

Dr. David Kirkby wrote:
> Here's my attempt to build sage 3.0.2 on Solaris (SPARC).
>
> The build process reports gmp_aux.h is not found, I checked and there
> is no such file. However, this in itself does not cause the build
> process to stop, but it later stops when various things are
> undefined.
>
> See below.
>
> The system in a Sun Blade 2000 running Solaris 10 update 4. gcc 4.0.2
> from Blastwave, and gnu make.
>
>
> I noticed gmp_aux.h exists in Singlular I have on the disk, but I'm
> not sure if that is the correct version. In any case, it needs
> fixing.
>
> Dave
>
>
> [EMAIL PROTECTED]:[~/sage-3.0.2] $ make SAGE_PORT=45
> 
> x ntl-5.4.2.p3/src/src/pair_GF2EX_long.c, 385 bytes, 1 tape blocks
> x ntl-5.4.2.p3/src/src/DispSettings.c, 2197 bytes, 5 tape blocks
> x ntl-5.4.2.p3/src/src/pair_lzz_pX_long.c, 386 bytes, 1 tape blocks
> Finished extraction
> 
> Host system
> uname -a:
> SunOS kestrel 5.10 Generic_120011-14 sun4u sparc SUNW,Sun-Blade-1000
> 
> 
> GCC Version
> gcc -v
> Reading specs from /usr/local/opt/csw/gcc4/bin/../lib/gcc/sparc-sun-
> solaris2.8/4.0.2/specs
> Target: sparc-sun-solaris2.8
> Configured with: ../sources/gcc-4.0.2/configure --prefix=/opt/csw/gcc4
> --with-local-prefix=/opt/csw --without-gnu-as --with-as=/usr/ccs/bin/
> as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --
> enable-shared --enable-multilib --enable-nls --with-included-gettext --
> with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --with-
> system-zlib --enable-languages=c,c++,f95,java,objc,ada
> Thread model: posix
> gcc version 4.0.2
> 
> writing makefile
> writing ../include/NTL/config.h
> Building and install NTL
> make[2]: Entering directory `/export/home/drkirkby/sage-3.0.2/spkg/
> build/ntl-5.4.2.p3/src/src'
> rm -f FFT.o FacVec.o GF2.o GF2E.o GF2EX.o GF2EXFactoring.o GF2X.o
> GF2X1.o GF2XFactoring.o GF2XVec.o GetTime.o HNF.o ctools.o LLL.o
> LLL_FP.o LLL_QP.o LLL_RR.o LLL_XD.o RR.o WordVector.o ZZ.o ZZVec.o
> ZZX.o ZZX1.o ZZXCharPoly.o ZZXFactoring.o ZZ_p.o ZZ_pE.o ZZ_pEX.o
> ZZ_pEXFactoring.o ZZ_pX.o ZZ_pX1.o ZZ_pXCharPoly.o ZZ_pXFactoring.o
> fileio.o lip.o lzz_p.o lzz_pE.o lzz_pEX.o lzz_pEXFactoring.o lzz_pX.o
> lzz_pX1.o lzz_pXCharPoly.o lzz_pXFactoring.o mat_GF2.o mat_GF2E.o
> mat_RR.o mat_ZZ.o mat_ZZ_p.o mat_ZZ_pE.o mat_lzz_p.o mat_lzz_pE.o
> mat_poly_ZZ.o mat_poly_ZZ_p.o mat_poly_lzz_p.o pair_GF2EX_long.o
> pair_GF2X_long.o pair_ZZX_long.o pair_ZZ_pEX_long.o pair_ZZ_pX_long.o
> pair_lzz_pEX_long.o pair_lzz_pX_long.o quad_float.o tools.o vec_GF2.o
> vec_GF2E.o vec_GF2XVec.o vec_RR.o vec_ZZ.o vec_ZZVec.o vec_ZZ_p.o
> vec_ZZ_pE.o vec_double.o vec_long.o vec_lzz_p.o vec_lzz_pE.o
> vec_quad_float.o vec_vec_GF2.o vec_vec_GF2E.o vec_vec_RR.o
> vec_vec_ZZ.o vec_vec_ZZ_p.o vec_vec_ZZ_pE.o vec_vec_long.o
> vec_vec_lzz_p.o vec_vec_lzz_pE.o vec_xdouble.o xdouble.o G_LLL_FP.o
> G_LLL_QP.o G_LLL_XD.o G_LLL_RR.o vec_ulong.o vec_vec_ulong.o # clean,
> preserving tuning parameters
> make shobj
> make[3]: Entering directory `/export/home/drkirkby/sage-3.0.2/spkg/
> build/ntl-5.4.2.p3/src/src'
> g++ -I../include -I.  -O2 -g  -fPIC -fPIC -c FFT.c
> In file included from ../include/NTL/tools.h:5,
>  from ../include/NTL/vector.h:5,
>  from ../include/NTL/vec_long.h:5,
>  from ../include/NTL/FFT.h:6,
>  from FFT.c:3:
> ../include/NTL/ctools.h:6:27: error: NTL/mach_desc.h: No such file or
> directory
> In file included from ../include/NTL/ZZ.h:18,
>  from ../include/NTL/FFT.h:7,
>  from FFT.c:3:
> ../include/NTL/lip.h:10:25: error: NTL/gmp_aux.h: No such file or
> directory
> ../include/NTL/tools.h: In function 'void NTL::conv(int&, long int)':
> ../include/NTL/tools.h:171: error: 'NTL_BITS_PER_INT' was not declared
> in this scope
> ../include/NTL/tools.h:171: error: 'NTL_MIN_INT' was not declared in
> this scope
> ../include/NTL/tools.h: In function 'void NTL::conv(int&, unsigned
> int)':
> ../include/NTL/tools.h:176: error: 'NTL_BITS_PER_INT' was not declared
> in this scope
> ../include/NTL/tools.h:176: error: 'NTL_MIN_INT' was not declared in
> this scope
> ../include/NTL/tools.h: In function 'void NTL::conv(int&, long
> unsigned int)':
> ../include/NTL/tools.h:179: error: 'NTL_BITS_PER_INT' was not declared
> in this scope
> ../include/NTL/tools.h:179: error: 'NTL_MIN_INT' was not declared in
> this scope
> ../include/NTL/tools.h: In function 'int NTL::to_int(long int)':
> ../include/NTL/tools.h:183: error: 'NTL_BITS_PER_INT' was not declared
> in this scope
> ../include/NTL/tools.h:183: error: 'NTL_MIN_INT' was not declared in
> this scope
> ../include/NTL/tools.h: In function 'int NTL::to_int(unsigned int)':
> ../include/NTL/tools.h:188: error: 'NTL_BITS_PER_INT' was not declared

[sage-devel] Re: problems building sage documentation

[William Stein]

On Jan 7, 2008 10:55 AM, Pablo De Napoli <[EMAIL PROTECTED]> wrote:
>
>
> I've managed to solve the problem: The package
> texlive-cyrillic (in Debian/Ubuntu) is needed to build the Sage
> documentation.

Thanks!!

I've made this trac #1719

   http://trac.sagemath.org/sage_trac/ticket/1719

>
> Pablo
>
> El Tuesday 01 January 2008 21:25:35 Pablo De Napoli escribió:
>
> > When building Sage documentation
> > (make in devel/doc), I've got a strange message
> > (I quote below the output)
> >
> > 
> >
> > TEXINPUTS=/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/commontex
> >: python
> > /media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/tools/mkhowto
> > --html --about html/stdabout.dat --iconserver ../icons --favicon
> > ../icons/pyfav.png --address "See About this
> > document... for information on suggesting changes." --up-link
> > ../index.html --up-title "SAGE Documentation Index" --global-module-index
> > "../modindex.html" --dvips-safe --dir html/ref ref/ref.tex
> > +++
> > TEXINPUTS=/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/ref:/medi
> >a/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/commontex:/media/hda2/pab
> >lo.new_home/sage/sage-2.9/devel/doc-main/paper-letter:/media/hda2/pablo.new_
> >home/sage/sage-2.9/devel/doc-main/texinputs: +++ latex ref
> > *** Session transcript and error messages are
> > in
> > /media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/html/ref/ref.how.
> > *** Exited with status 1.
> > The relevant lines from the transcript are:
> > 
> > +++ latex ref
> > This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
> >  %&-line parsing enabled.
> > entering extended mode
> > (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/ref/ref.tex
> > LaTeX2e <2005/12/01>
> > Babel  and hyphenation patterns for english, usenglishmax, dumylang,
> > noh
> > yphenation, spanish, catalan, galician, spanish, catalan, galician, loaded.
> > (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/texinputs/manual.c
> >ls Document Class: manual 1998/03/03 Document class (Python manual)
> > (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/texinputs/pypaper.
> >sty)
> >
> > (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/texinputs/fancybox
> >.sty Style option: `fancybox' v1.3 <2000/09/19> (tvz)
> > ) (/usr/share/texmf-texlive/tex/latex/base/report.cls
> > Document Class: report 2005/09/16 v1.4f Standard LaTeX document class
> > (/usr/share/texmf-texlive/tex/latex/base/size12.clo))
> > (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/texinputs/fancyhdr
> >.sty )
> > Using fancier footers than usual.
> >
> > (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/texinputs/fncychap
> >.sty )
> > Using fancy chapter headings.
> > (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/texinputs/python.s
> >ty (/usr/share/texmf-texlive/tex/latex/tools/longtable.sty)
> > (/usr/share/texmf-texlive/tex/latex/tools/verbatim.sty)
> > (/usr/share/texmf-texlive/tex/latex/graphics/color.sty
> > (/etc/texmf/tex/latex/config/color.cfg)
> > (/usr/share/texmf-texlive/tex/latex/graphics/dvips.def)
> > (/usr/share/texmf-texlive/tex/latex/graphics/dvipsnam.def
> > (/usr/share/texmf-texlive/tex/latex/base/textcomp.sty
> > (/usr/share/texmf-texlive/tex/latex/base/ts1enc.def))
> > (/usr/share/texmf-texlive/tex/latex/amsmath/amsmath.sty
> > For additional information on amsmath, use the `?' option.
> > (/usr/share/texmf-texlive/tex/latex/amsmath/amstext.sty
> > (/usr/share/texmf-texlive/tex/latex/amsmath/amsgen.sty))
> > (/usr/share/texmf-texlive/tex/latex/amsmath/amsbsy.sty)
> > (/usr/share/texmf-texlive/tex/latex/amsmath/amsopn.sty))
> > (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/commontex/macros.t
> >ex (/usr/share/texmf-texlive/tex/latex/tools/xspace.sty))
> > (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/commontex/boilerpl
> >ate. tex
>
> > (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/commontex/patchlev
> >el.t ex))
> > Writing index file ref.idx
> > (./ref.aux) (/usr/share/texmf-texlive/tex/latex/base/ts1cmr.fd)
> > No file OT2cmr.fd.
> >
> > ! LaTeX Error: This NFSS system isn't set up properly.
> >
> > See the LaTeX manual or LaTeX Companion for explanation.
> > Type  H   for immediate help.
> >  ...
> >
> > l.28 \begin{document}
> >
> > ?
> > ! Emergency stop.
> >  ...
> >
> > l.28 \begin{document}
> >
> > No pages of output.
> > Transcript written on ref.log.
> > *** Session transcript and error messages are
> > in
> > /media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/html/ref/ref.how.
> > *** Exited with status 1.
> > make: *** [html/ref/ref.html] Error 1
> >
> > 
> >
> > Any idea of what might be happening?
> > It seems to be a bug in my tex instalation rather than a bug in Sage
> > (I'm using texlive from Ubuntu Gutsy)
> >
> > Pablo
>
>
>
> >
>



-- 
William Stein
Associate Professor of Mathematics
University of Washington
htt

[sage-devel] Re: problems building sage documentation

[Pablo De Napoli]

I've managed to solve the problem: The package 
texlive-cyrillic (in Debian/Ubuntu) is needed to build the Sage 
documentation.

Pablo

El Tuesday 01 January 2008 21:25:35 Pablo De Napoli escribió:
> When building Sage documentation
> (make in devel/doc), I've got a strange message
> (I quote below the output)
>
> 
>
> TEXINPUTS=/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/commontex
>: python
> /media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/tools/mkhowto
> --html --about html/stdabout.dat --iconserver ../icons --favicon
> ../icons/pyfav.png --address "See About this
> document... for information on suggesting changes." --up-link
> ../index.html --up-title "SAGE Documentation Index" --global-module-index
> "../modindex.html" --dvips-safe --dir html/ref ref/ref.tex
> +++
> TEXINPUTS=/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/ref:/medi
>a/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/commontex:/media/hda2/pab
>lo.new_home/sage/sage-2.9/devel/doc-main/paper-letter:/media/hda2/pablo.new_
>home/sage/sage-2.9/devel/doc-main/texinputs: +++ latex ref
> *** Session transcript and error messages are
> in
> /media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/html/ref/ref.how.
> *** Exited with status 1.
> The relevant lines from the transcript are:
> 
> +++ latex ref
> This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
>  %&-line parsing enabled.
> entering extended mode
> (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/ref/ref.tex
> LaTeX2e <2005/12/01>
> Babel  and hyphenation patterns for english, usenglishmax, dumylang,
> noh
> yphenation, spanish, catalan, galician, spanish, catalan, galician, loaded.
> (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/texinputs/manual.c
>ls Document Class: manual 1998/03/03 Document class (Python manual)
> (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/texinputs/pypaper.
>sty)
>
> (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/texinputs/fancybox
>.sty Style option: `fancybox' v1.3 <2000/09/19> (tvz)
> ) (/usr/share/texmf-texlive/tex/latex/base/report.cls
> Document Class: report 2005/09/16 v1.4f Standard LaTeX document class
> (/usr/share/texmf-texlive/tex/latex/base/size12.clo))
> (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/texinputs/fancyhdr
>.sty )
> Using fancier footers than usual.
>
> (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/texinputs/fncychap
>.sty )
> Using fancy chapter headings.
> (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/texinputs/python.s
>ty (/usr/share/texmf-texlive/tex/latex/tools/longtable.sty)
> (/usr/share/texmf-texlive/tex/latex/tools/verbatim.sty)
> (/usr/share/texmf-texlive/tex/latex/graphics/color.sty
> (/etc/texmf/tex/latex/config/color.cfg)
> (/usr/share/texmf-texlive/tex/latex/graphics/dvips.def)
> (/usr/share/texmf-texlive/tex/latex/graphics/dvipsnam.def
> (/usr/share/texmf-texlive/tex/latex/base/textcomp.sty
> (/usr/share/texmf-texlive/tex/latex/base/ts1enc.def))
> (/usr/share/texmf-texlive/tex/latex/amsmath/amsmath.sty
> For additional information on amsmath, use the `?' option.
> (/usr/share/texmf-texlive/tex/latex/amsmath/amstext.sty
> (/usr/share/texmf-texlive/tex/latex/amsmath/amsgen.sty))
> (/usr/share/texmf-texlive/tex/latex/amsmath/amsbsy.sty)
> (/usr/share/texmf-texlive/tex/latex/amsmath/amsopn.sty))
> (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/commontex/macros.t
>ex (/usr/share/texmf-texlive/tex/latex/tools/xspace.sty))
> (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/commontex/boilerpl
>ate. tex
> (/media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/commontex/patchlev
>el.t ex))
> Writing index file ref.idx
> (./ref.aux) (/usr/share/texmf-texlive/tex/latex/base/ts1cmr.fd)
> No file OT2cmr.fd.
>
> ! LaTeX Error: This NFSS system isn't set up properly.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H   for immediate help.
>  ...
>
> l.28 \begin{document}
>
> ?
> ! Emergency stop.
>  ...
>
> l.28 \begin{document}
>
> No pages of output.
> Transcript written on ref.log.
> *** Session transcript and error messages are
> in
> /media/hda2/pablo.new_home/sage/sage-2.9/devel/doc-main/html/ref/ref.how.
> *** Exited with status 1.
> make: *** [html/ref/ref.html] Error 1
>
> 
>
> Any idea of what might be happening?
> It seems to be a bug in my tex instalation rather than a bug in Sage
> (I'm using texlive from Ubuntu Gutsy)
>
> Pablo



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---