On Thu, 27 Mar 2014 20:29:29 leif wrote: > kcrisman wrote: > > On Thursday, March 27, 2014 1:29:58 PM UTC-4, kcrisman wrote: > > > "eclib's test suite passed without errors" > > > > That sounds good -- you must therefore have a working version of > > mwrank (and what else would anyone need?) Sriously, this really > > does > > mean that the few binaries which eclib builds work OK. > > > > Not that I had any doubts! But the problem is that somehow the > > linking isn't happening properly in sage/libs/mwrank, and indeed > > -lflint isn't in the line > > > > g++ -bundle -undefined dynamic_lookup > > -L/Users/student/Desktop/sage-6.2.beta4/local/lib > > build/temp.macosx-10.4-ppc-2.7/sage/libs/mwrank/mwrank.o > > build/temp.macosx-10.4-ppc-2.7/sage/libs/mwrank/wrap.o > > -L/Users/student/Desktop/sage-6.2.beta4/local/lib -lcsage -lec -lntl > > -lpari -lgmp -lgmpxx -lstdc++ -lm -lstdc++ -lntl -o > > build/lib.macosx-10.4-ppc-2.7/sage/libs/mwrank/mwrank.so > > > > Maybe could I add something to src/module_list.py or whatever the > > appropriate file is now to force -lflint as well? On Cygwin we > > often had to be more explicit because of something analogous, if I > > recall that correctly. I'm going to try this just to see... > > > > It seems to work! At least, things continue compiling. On Cygwin > > that was always the sign of victory, though :) > > > > Indeed, all of sage.libs.cremona needed this addition to the > > module_list.py as well. I don't see how this hurts, so I'm probably > > going to suggest this on the > > ticket http://trac.sagemath.org/ticket/16017 - John, any thoughts? (Or > > Leif or JP?) > > Well, since it is illogical ;-) , we should make the addition > platform-dependent (apparently MacOS X 10.4 / Darwin 8 only, not Darwin > in general, and presumably Cygwin as well). > > But someone familiar with flat vs. two-level namespace etc. can probably > tell better. (Adding or dropping some option on Darwin 8 might be > sufficient as well.) > > > Still puzzled by the original "file not found" linker > <strike>error</strike> warning: > > ... > g++ -bundle -undefined dynamic_lookup > -L/Users/student/Desktop/sage-6.2.beta4/local/lib > build/temp.macosx-10.4-ppc-2.7/sage/libs/mwrank/mwrank.o > build/temp.macosx-10.4-ppc-2.7/sage/libs/mwrank/wrap.o > -L/Users/student/Desktop/sage-6.2.beta4/local/lib -lcsage -lec -lntl > -lpari -lgmp -lgmpxx -lstdc++ -lm -lstdc++ -lntl -o > build/lib.macosx-10.4-ppc-2.7/sage/libs/mwrank/mwrank.so > /usr/bin/ld: warning can't open dynamic library: libflint.dylib > referenced from: > /Users/student/Desktop/sage-6.2.beta4/local/lib/libec.dylib (checking > for undefined symbols may be affected) (No such file or directory, errno > = 2) > /usr/bin/ld: Undefined symbols: > _nmod_mat_clear referenced from libec expected to be defined in > libflint.dylib > _nmod_mat_init referenced from libec expected to be defined in > libflint.dylib > _nmod_mat_rref referenced from libec expected to be defined in > libflint.dylib > collect2: error: ld returned 1 exit status > error: command 'g++' failed with exit status 1 >
libflint is probably referenced in libec but it doesn't know how to access it. Adding -lflint will of course solves the problem. But equally something may be doable to get libec to know where libflint is. Looking at my machine with maverick my suspicion is that because libflint doesn't have its install_name set, the non-definition is propagated to libec. Later OS X probably have better library look up mechanism which is why you don't get the problem. According to best practice on OS X flint should be fixed. Explicitly linking to libflint is OK with me. It doesn't hurt and you could argue that it is the right thing to do in the first place. The only reason it wasn't done before was probably to be economical with the patching required. > > ... and then, why does the linker bail out despite '-undefined > dynamic_lookup'? Why '-bundle' instead of '-dy[namic]lib'? > That is perfectly normal for a python module. Python module are shared object but they are not in actual fact libraries, more like plugins. In linux that distinction is very blurry but on OS X it is very well defined. In sage-on-gentoo run on a OS X prefix sage extension do not have a .so suffix but a .bundle one. In fact making a ".so" object causes portage QA to issue dire warnings. In fact I think last time it happened it outright refused to install. I think to get python to use .bundle instead of .so you have to install it as a "framework" which isn't done in vanilla sage. Francois -- You received this message because you are subscribed to the Google Groups "sage-release" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-release. For more options, visit https://groups.google.com/d/optout.
