François Bissey wrote:
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.
Well, eclib doesn't have to (after it's been built at least); that
should be up to the dynamic linker... ;-)
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.
Yes, it might be a name / version issue, with just the linker message
being misleading ("file not found", although explicitly errno=2, too).
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.
I don't agree (and I am not alone... :-) ).
If your application (or library) A uses some library B, you should *not*
specify / directly link with anything B (currently!) happens to use (C
and D, say), unless A itself directly depends on / uses (some of) these,
for a couple of reasons.
First of all, you shouldn't at all have to know what B uses. (If you
want to install / build B, look at *its* documentation, although usually
a package manager or build system will do the necessary work.)
Each time the dependencies of B change, you'd have to rebuild A (besides
changing its build scripts). This includes any upgrades to C or D, as
well as the cases when B stops to use C, starts to prefer using E
instead of D, or adds another library. And C, D and E may use further
libraries in turn...
Linking to not directly used libraries is confusing and misleading (and
by the way also a waste of time during linking and loading). It's
pretty hard to find out which libraries *aren't* actually used -- it's
by far easier to add a library in case A one day starts to use C or D
directly.
(This applies to dynamic linking; with static libraries, things are
different of course.)
The only reason
it wasn't done before was probably to be economical with the patching
required.
I don't think so. We deleted a few (but not all IIRC) useless libraries
/ false dependencies from module_list entries a while ago.
At least some of them really caused trouble when upgrading, because an
obsolete library just *listed* as a dependency (in the NEEDED tags) got
pulled in instead of and before the newer one (by the libraries that
really needed it).
-leif
... 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
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
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.
