-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
octave-3.0.5 builds with glpk-4.26, but not with the recent glpk-4.44
update. The failure mode is as follows:
...
g++ -bundle -bundle_loader ../src/octave -L/sw32/lib -o __glpk__.oct
pic/__glpk__.o -L../libcruft -lcruft -L../liboctave -loctave -L.
- -loctinterp -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd
- -lcxsparse
-
-Wl,-framework,Accelerate,-dylib_file,/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib:/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
-
-Wl,-framework,Accelerate,-dylib_file,/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib:/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
- -lfftw3 -lreadline -lncurses -lhdf5 -lz -lm
/sw32/lib/gcc4.4/lib/libgfortran.dylib -lglpk
Undefined symbols:
"__glp_lib_fault_hook", referenced from:
glpk(int, int, int, double*, int, int*, int*, double*, double*,
char*, int*, double*, int*, double*, int*, int, int, int, double*,
double*, double*, double*, double*, double*, double*)in __glpk__.o
"__glp_lib_print_hook", referenced from:
glpk(int, int, int, double*, int, int*, int*, double*, double*,
char*, int*, double*, int*, double*, int*, int, int, int, double*,
double*, double*, double*, double*, double*, double*)in __glpk__.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [__glpk__.oct] Error 1
The issue appears to be due to the symbol content being different
between libglpk.0.dylib in the two versions:
glpk-4.26-1:
$ nm /sw/lib/libglpk.0.dylib | c++filt | grep hook
00020070 T __glp_lib_fault_hook
00020080 T __glp_lib_print_hook
00020020 T __glp_lib_term_hook
00009c10 T _glp_term_hook
glpk-4.44-1:
$ nm /sw32/lib/libglpk.0.dylib | c++filt | grep hook
0002da60 T _glp_error_hook
0002d830 T _glp_term_hook
In principle I could patch octave not to try to use __glp_lib_fault_hook
and __glp_lib_print_hook, as long as nobody knows of a reason why this
would be bad. I haven't experienced any _runtime_ issues with octave
built against glpk-4.26 and then using 4.44, so it doesn't seem to need
those symbols frequently, if it actually does.
(Updating octave might be a better option, but I'm still a bit too busy
to be able to handle that chore.)
- --
Alexander Hansen
Fink User Liaison
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyVRcAACgkQB8UpO3rKjQ+JUgCeJNvQ3yquSETTuSLssFWYrVZl
lrMAniE/kXmlrmdFaBZ6c/p/IQMxds9R
=gl94
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
