Jean-Francois Mertens wrote:
> Dominique Dhumieres wrote:
>
>>That was it! after rebuilding octave, plplot rebuilt without
>>further problem.
>
>
>
> For the record, since this is on the -devel list, and since a
> priori rebuilding a pkg changes nothing, let me explain here
> (my tentative interpretation of) roughly what happened :
> _ during the half-hour where "octave-atlas" was by accident
> committed, Dominique did a selfupdate.
> _ some time afterwards, he did a 'fink install octave-atlas';
> the command went successfully to the end, and he didn't
> notice error messages from dpkg at the end saying in essence
> that the pkg was unpacked but could not be configured _
> this because of a line "Provides: octave" in the info file,
> (which is no longer there in my private version).
> _ so fink continued to show "octave" as installed, although
> although in fact it was octave-atlas; and in that private
> version octave-atlas didn't yet have the dep on atlas-shlibs.
And to complete the story with a dark chapter, also for the record:
After Dominique had built octave-atlas, he had the prerequisite
atlas-shlibs installed, and then he was unable to build octave, because
it failed with
Undefined symbols:
"_lsame_", referenced from:
_xzlange_ in xzlange.o
_xzlange_ in xzlange.o
_xzlange_ in xzlange.o
_xzlange_ in xzlange.o
_xzlange_ in xzlange.o
ld: symbol(s) not found
(see message to fink-users on December 25 and subsequent discussion,
some of it private).
The reason is that as long as you have /sw/lib/liblapack.dylib
installed, any linker command that uses -framework vecLib or -framework
Accelerate will fail on Leopard. This is caused by the same bug in
/usr/bin/ld that makes us change hundreds of packages to avoid the
infamous "cycle in re-exports" error when linking with
/usr/X11/lib/libGL.dylib.
When you have -L/sw/lib on the linker line and you have
/sw/lib/liblapack.dylib installed, then Leopard's braindead /usr/bin/ld
will load /sw/lib/liblapack.dylib when vecLib asks it to load
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib.
One would then need a
-Wl,-dylib_file,/System/.../libLAPACK.dylib,/System/.../libLAPACK.dylib
command on that linker line, and a similar one for libBLAS.dylib, in
order to work around that bug.
I think we should step up pressure on Apple to fix that bug (or to
change that "feature", as they will call it, because it is even proudly
mentioned in the ld man page).
I have seen another instance where it leads to fatal crashes, namely
when you try to link to any library (such as
libboost_python-1_34_1.dylib) that is linked with
/sw/lib/python2.5/config/libpython2.5.dylib. Leopard's /usr/bin/ld will
then load /usr/lib/libpython2.5.dylib instead, and the resulting
executable will fail with a "python version mismatch" error.
--
Martin
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
