On Sat, 18 Sep 2010 19:05:36 -0400, Alexander Hansen wrote: > > 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.) More info (from #fink debug-fest about it)... those symbols were not part of public interface of glpk (no prototype in installed .h) and was commented as "obsolete" in the internal coding. Octave source gives hints that octave devels even knew it was private, so data point N 1 that relying on someone else's internal implementation details is fragile and dumb. dan
-- Daniel Macks dma...@netspace.org ------------------------------------------------------------------------------ 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
