Wrong library order breaks build on Ubuntu 11.10

[leif <not.really@…>]

Due to stricter linker semantics, on the upcoming Ubuntu 11.10 (Oneiric Ocelot) the build fails with for example:

../kernel/libkernel.a(mod_raw.o): In function `dynl_open':
.../singular-3-1-1-4.p13/src/kernel/mod_raw.cc:217: undefined reference to `dlopen'
../kernel/libkernel.a(mod_raw.o): In function `dynl_sym':
.../singular-3-1-1-4.p13/src/kernel/mod_raw.cc:228: undefined reference to `dlsym'
../kernel/libkernel.a(mod_raw.o): In function `dynl_close':
.../singular-3-1-1-4.p13/src/kernel/mod_raw.cc:233: undefined reference to `dlclose'
../kernel/libkernel.a(mod_raw.o): In function `dynl_error':
.../singular-3-1-1-4.p13/src/kernel/mod_raw.cc:238: undefined reference to `dlerror'
collect2: ld returned 1 exit status
make[2]: *** [iparith.inc] Error 1
make[2]: Leaving directory `.../singular-3-1-1-4.p13/src/Singular'
make[1]: *** [install] Error 1
make[1]: Leaving directory `.../singular-3-1-1-4.p13/src'
make: *** [/home/foo/sage-4.7.2.alpha2/local/bin/Singular-3-1-1] Error 2
Unable to build Singular.

(From a Sage build with Singular 3-1-1-4, but this hasn't changed in 3-1-3-2, nor svn 14378.)

This is because in (e.g.) Singular/Makefile.in, we have:

...
LDFLAGS         = -L@prefix@/kernel -L../kernel -lkernel @LDFLAGS@
...
LD_DYN_FLAGS    = @LD_DYN_FLAGS@   # On Linux, gets "-rdynamic -ldl"
...
LDFLAGS  := ${LD_DYN_FLAGS} ${LDFLAGS}
...

Singular${S_EXT}: mod2.h Makefile version.h $(WIN_LIBS) scanner.cc  ${OBJS} \
          iparith.o tesths.cc libparse.cc claptmpl.o mpsr_Tok.o $(DL_LIBS)
        ${CXX} ${CXXFLAGS} ${CPPFLAGS} ${CXXTEMPLFLAGS} ${DEFS} \
          -o Singular${S_EXT} \
          tesths.cc iparith.o mpsr_Tok.o claptmpl.o\
          ${OBJS} ${LDFLAGS} ${LIBS} ../kernel/mmalloc.o

(Neither the [default] LDFLAGS from configure nor ${LIBS} contain -ldl.)

Similar situation for other make targets (and Makefiles) IIRC.

Cf. [trac.sagemath.org/sage_trac/ticket/11769 this Sage trac ticket].
(I've removed the http:... because last time I tried, the post was rejected as alleged spam. No idea how one gets an account here; Simon King also didn't recall.)

As a temporary work-around, the build succeeds if one in addition adds -ldl to the environment variable LDFLAGS before running configure.

-leif

[leif <not.really@…>]

P.S.: This is the actual command that failed above (there are hundreds of warnings inbetween):

g++ -O2 -g -fPIC -pipe -I. -I../kernel -I/home/foo/sage-4.7.2.alpha2/local/include -I/home/foo/sage-4.7.2.alpha2/local/include -I/home/foo/sage-4.7.2.alpha2/local/include  -fno-implicit-templates -DNDEBUG -DOM_NDEBUG -Dix86_Linux -DHAVE_CONFIG_H -DGENTABLE \
	     -o gentable1 claptmpl.o iparith.cc tesths.cc mpsr_Tok.cc \
	     grammar.o scanner.o attrib.o eigenval_ip.o extra.o fehelp.o feOpt.o ipassign.o ipconv.o ipid.o iplib.o ipprint.o ipshell.o lists.o sdb.o fglm.o interpolation.o silink.o subexpr.o janet.o wrapper.o libparse.o sing_win.o gms.o pcv.o maps_ip.o walk.o walk_ip.o cntrlc.o misc_ip.o calcSVD.o Minor.o MinorProcessor.o MinorInterface.o  slInit_Dynamic.o -ldl -rdynamic -L../kernel -lkernel -L/home/foo/sage-4.7.2.alpha2/local/lib -L/home/foo/sage-4.7.2.alpha2/local/lib  -lm -lsingfac -lsingcf -lntl -lgmp -lreadline -ltermcap -lm  -lomalloc_ndebug ../kernel/mmalloc.o

[hannes]

flags for dynamic loading split into one for the start and one for the end. fixed with revision 14381.

Seems to be a mis-feature (do not know of ubuntu or ld): if a library should be linked in, it should be linked in and not ignored (see also --as-needed). But if the gods decided that we should jump we can only ask about the height.

[leif <not.really@…>]

Replying to hannes:

flags for dynamic loading split into one for the start and one for the end.

Changing

LDFLAGS  := ${LD_DYN_FLAGS} ${LDFLAGS}

to

LDFLAGS  :=  ${LDFLAGS} ${LD_DYN_FLAGS}

would perhaps have been enough, though not very "clean".

fixed with revision 14381.

Thanks.

Seems to be a mis-feature (do not know of ubuntu or ld): if a library should be linked in, it should be linked in and not ignored

Maybe you have some misconception about the linker and libraries. ;-)

The current behaviour of Oneiric's linker is exactly what it used to be from the very beginning; only some "smart" linkers later accepted what is in principle invalid.

If you specify a (static) library with -l... in a linker command, that doesn't mean "put all stuff from that library into the executable", but instead "if you can resolve some of the so far undefined symbols from some module in that library, link in that module". Note that the linker normally doesn't "remember" any other symbols (from other modules) of a library, so if further references to symbols defined in other modules of a library occur later, the library has to be specified again to resolve these.

(The -rdynamic / --export-dynamic doesn't refer to libraries specified, i.e., also doesn't pull in "more" symbols from these; it only refers to the file created by the linker, the final executable.)

But if the gods decided that we should jump we can only ask about the height.

Amen. Wasn't that high though, was it?