Opened 11 years ago

Closed 11 years ago

Last modified 5 years ago

#8844 closed defect (fixed)

add missing libraries to module_list for Cygwin (and Fedora, OpenSuSE, ...)

Reported by: mhansen Owned by: tbd
Priority: major Milestone: sage-4.4.3
Component: build Keywords: missing library, unresolved symbol
Cc: leif, robertwb Merged in: sage-4.4.3.alpha0
Authors: Mike Hansen Reviewers: Leif Leonhardy, William Stein
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by jdemeyer)

Cygwin is a lot pickier about missing symbols so more libraries need to be linked in to the extension modules. This also fixes some issues on other systems: see then end of this thread http://www.mail-archive.com/sage-devel@googlegroups.com/msg38859.html

Follow-up: #19606

Attachments (2)

trac_8844-module_list.patch (13.1 KB) - added by mhansen 11 years ago.
trac_8844-reviewer.patch (932 bytes) - added by leif 11 years ago.
Reviewer patch, s/png/png12/ once as mentioned

Download all attachments as: .zip

Change History (22)

Changed 11 years ago by mhansen

comment:1 Changed 11 years ago by mhansen

  • Status changed from new to needs_review

comment:2 Changed 11 years ago by mhansen

  • Component changed from cygwin to build
  • Description modified (diff)
  • Summary changed from add missing libraries to module_list for Cygwin to add missing libraries to module_list for Cygwin (and Fedora,...)

comment:3 Changed 11 years ago by leif

  • Cc leif added

comment:4 follow-up: Changed 11 years ago by leif

  • Status changed from needs_review to needs_work

s/'png'/'png12'/ (once).

comment:5 in reply to: ↑ 4 Changed 11 years ago by leif

(Or we should create symbolic links from libpng.so* to libpng12.so*.)

comment:6 Changed 11 years ago by mhansen

Symbolic links don't work for linking libraries in Cygwin.

Changed 11 years ago by leif

Reviewer patch, s/png/png12/ once as mentioned

comment:7 Changed 11 years ago by leif

  • Cc robertwb added
  • Status changed from needs_work to needs_review

Now trying to rebase #7987 on this one...

comment:8 Changed 11 years ago by leif

  • Keywords missing library unresolved symbol added
  • Summary changed from add missing libraries to module_list for Cygwin (and Fedora,...) to add missing libraries to module_list for Cygwin (and Fedora, OpenSuSE, ...)

Works for OpenSuSE 11.2: http://groups.google.com/group/sage-devel/msg/1078faf7f0c6ec48

(And most probably will for Fedora 13, too, which is released in a few days.)

comment:9 follow-up: Changed 11 years ago by leif

It seems the whole Sage library build process needs clean-ups... (i.e. local/bin/sage-build, devel/sage/module_list.py, devel/sage/setup.py, and perhaps devel/sage/c_lib/SConstruct)

Btw, at least all Sage library C files (of course including those generated by cython) compile with gcc and -std=c99 [-pedantic], though not really standard-conformant. (C++ files currently don't, neither with -std=c++98 nor c++0x.)

comment:10 Changed 11 years ago by mhansen

Thanks for the review patch. We'll hopefully get this merged this evening.

comment:11 Changed 11 years ago by was

  • Merged in set to 4.4.3.alpha0
  • Resolution set to fixed
  • Reviewers set to wstein
  • Status changed from needs_review to closed

comment:12 Changed 11 years ago by mvngu

  • Merged in changed from 4.4.3.alpha0 to sage-4.4.3.alpha0
  • Reviewers changed from wstein to Leif Leonhardy, William Stein

comment:13 follow-up: Changed 11 years ago by mhansen

The reviewer patch actually breaks things on Cygwin. It should be reverted.

comment:14 in reply to: ↑ 13 Changed 11 years ago by leif

Replying to mhansen:

The reviewer patch actually breaks things on Cygwin. It should be reverted.

How can that be? At least on Linux, there's no libpng.so, just libpng12.so, so reverting it wouldn't build on other systems.

comment:15 in reply to: ↑ 9 ; follow-up: Changed 11 years ago by drkirkby

Replying to leif:

Btw, at least all Sage library C files (of course including those generated by cython) compile with gcc and -std=c99 [-pedantic], though not really standard-conformant. (C++ files currently don't, neither with -std=c++98 nor c++0x.)

The problem with c_lib/SConstruct is that nobody to my knowledge knows SCons well. I know it needs something to add the -m64 flag to CFLAGS, CXXFLAGS and LDFLAGS on platforms other than OS X (darwin). Something like (untested)

if env['PLATFORM'] != "darwin" and os.environ['SAGE64']=="yes" 
        env.Append( CFLAGS="-O2 -g -m64" )
        env.Append( CXXFLAGS="-O2 -g -m64" )
        env.Append( LINKFLAGS="-m64" )

This seems a problem in general with Sage and SCons - nobody really knows what they are doing with it.

Dave

comment:16 in reply to: ↑ 15 Changed 11 years ago by drkirkby

Replying to drkirkby:

Replying to leif:

Btw, at least all Sage library C files (of course including those generated by cython) compile with gcc and -std=c99 [-pedantic], though not really standard-conformant. (C++ files currently don't, neither with -std=c++98 nor c++0x.)

The problem with c_lib/SConstruct is that nobody to my knowledge knows SCons well. I know it needs something to add the -m64 flag to CFLAGS, CXXFLAGS and LDFLAGS on platforms other than OS X (darwin). Something like (untested)

if env['PLATFORM'] != "darwin" and os.environ['SAGE64']=="yes" 
        env.Append( CFLAGS="-O2 -g -m64" )
        env.Append( CXXFLAGS="-O2 -g -m64" )
        env.Append( LINKFLAGS="-m64" )

This seems a problem in general with Sage and SCons - nobody really knows what they are doing with it.

Dave

Oops, I posted my comment about SCons under the wrong comment. It was meant to be under that of leif, who wrote:

It seems the whole Sage library build process needs clean-ups... (i.e. local/bin/sage-build, devel/sage/module_list.py, devel/sage/setup.py, and perhaps devel/sage/c_lib/SConstruct)

Dave

comment:17 follow-up: Changed 5 years ago by jdemeyer

Did anybody remember why gmp was added as dependency to the various symbolic modules? I don't believe those actually depend on gmp. This change is partially responsible for #19602.

comment:18 Changed 5 years ago by jdemeyer

The linked thread does mention some problems with gmp, but not in the symbolic modules.

PS for @was: the fact that I'm even able to ask this question is because I can check the git history to see where this dependency was added. This is exactly what open development is about.

comment:19 Changed 5 years ago by jdemeyer

  • Description modified (diff)

comment:20 in reply to: ↑ 17 Changed 5 years ago by leif

Replying to jdemeyer:

Did anybody remember why gmp was added as dependency to the various symbolic modules? I don't believe those actually depend on gmp.

I can only guess this was some kind of overkill, caused by confusing the pynac extension module with the external Pynac library libpynac. While the former indeed uses GMP and hence needs to get linked with it (and in addition libpynac), the latter does not.

Note: See TracTickets for help on using tickets.