On Apr 12, 2008, at 7:03 PM, Jean-François Mertens wrote: > > On 12 Apr 2008, at 17:46, Ben Abbott wrote: >> >> I was hoping to extract the object code from the static libraries >> (using "ax -x libname.a") and then build the dylibs from that. Thus, >> I'd minimize changes the build process for SuiteSparse. >> > This is the correct approach. >> Any reason such an approach won't work? ... if so, and since I'm now >> confused, specifically what do you recommend I use regarding the >> options for gcc? >> >> Looking over atlas.info I see >> >> ld="ld -dynamic -dylib -single_module -dead_strip -x -all_load - >> L. -L%p/lib/gcc4.3/lib -ldylib1.o -dylib_install_name" >> $ld %p/lib/libatlas.dylib libatlas.a -o libatlas.dylib -lSystem >> >> The comments in atlas.info say; "We link 'manually', with ld, to >> avoid >> having unnecessary libs like lgcc_s among the load commands. This way >> the libs can be safely used in linking with any compiler: they will >> not bring themselves the wrong lgcc_s in the search list". >> >> So my second question is; Is it preferred to use gcc or ld to produce >> the dylibs? > Use gcc (at least for a first try) >> >> I also notice that the dylibs for atlas are built directly from the >> static libs. Is this possible for the gcc approach as well (a simpler >> task). > Sure, that is the "-all_load" flag; but I explained yesterday its > potential drawback. > This does not occur however if you use only gcc to link. > So you could use that; that way you create easily > (eg, for a first attempt, >> # for f in `find . -name *.a`; do gcc -dynamiclib -all_load $f -o >> `sed -r -e 's,\.a,.dylib,' <<<"$f"`; done > ) : >> # find . -name '*.dylib'|xargs ls -l >> -rwxr-xr-x 1 root admin 61156 Apr 12 18:36 ./AMD/Lib/libamd.dylib >> -rwxr-xr-x 1 root admin 37488 Apr 12 18:36 ./BTF/Lib/libbtf.dylib >> -rwxr-xr-x 1 root admin 65128 Apr 12 18:36 ./CAMD/Lib/libcamd.dylib >> -rwxr-xr-x 1 root admin 75824 Apr 12 18:36 ./CCOLAMD/Lib/ >> libccolamd.dylib >> -rwxr-xr-x 1 root admin 54340 Apr 12 18:36 ./COLAMD/Lib/ >> libcolamd.dylib >> -rwxr-xr-x 1 root admin 71932 Apr 12 18:36 ./CSparse/Lib/ >> libcsparse.dylib >> -rwxr-xr-x 1 root admin 203744 Apr 12 18:36 ./CXSparse/Lib/ >> libcxsparse.dylib >> -rwxr-xr-x 1 root admin 38072 Apr 12 18:36 ./LDL/Lib/libldl.dylib >> -rwxr-xr-x 1 root admin 32624 Apr 12 18:36 ./UFconfig/xerbla/ >> libcerbla.dylib > Those link according to otool to nothing else than libSystem. > You will want to eliminate from those libcsparse.dylib; for the > remaining .a archives, > (CHOLMOD/Lib/libcholmod.a, KLU/Lib/libklu.a, and UMFPACK/Lib/ > libumfpack.a) > you'll have to look at the missing symbols, and see in which of the > above dylibs > they might come, and add those dylibs on the link line (and only > those dylibs!, > for each one). > At worst you might have to repeat this procedure ... > > When all this works well you can start asking yourself which other > (stripping etc) > flags may be desirable, etc >> >> Third question; Regarding the names of the dylibs, should they be of >> the libname.0.dylib variety, with symbolic links of the libname.dylib >> variety? This isn't a problem either way, but as altas does not >> include the libname.o.dylib versions, I thought it best to ask. > > Right _ that is one of the more problematic issues.. > It IS unsafe to make dylibs (and a fortiori to version them) when > upstream > doesn't... You can think of a versioning scheme (eg like used in the > build > scripts you mentioned (Fedora ?)), but it can break down completely > when > upstream starts itsellf to version _ forcing you at least to go to > "epoch" type > maneuvers.. > So in this case, since only 1 pkg (octave) depends on this, I think > an ad > hoc policy is possible _ but it has to very well understood and kept > in mind > by the maintainers of both pkgs .. > > You should further realise that, if embarking on this, some of your > undefined > symbols refer to the blas, and that (cf point 1 in your README.txt : > "You should use an optimized BLAS; otherwise UMFPACK and CHOLMOD > will be slow." > > Using an optimized BLAS means using atlas; the current setup where > suitesparse > is purely static allows the choice of "what blas to link with" to be > determined by > the choice between octave and octave-atlas; but if the libs are to > become dylibs, > the choice is made at the suitesparse level. So either you follow > this "point 1", > and link to some atlas libs, but then octave "-noatlas" has to be > made w/o suitesparse, > or you have to provide both an atlas variant and a non-atlas variant > (the latter > linking to vecLib or the like for those symbols). > > Please, if you want nevertheless to pursue this, open a new tracker > item, and > assign it to me. > > Cheers, and good luck ! > > JF
Thanks JF, I'll get started on this later today. In my prior email I had neglected to mention that the various static libs are accompanied by *.def files. I'm not familiar with their purpose, but their content is ... $ cat libamd.def LIBRARY libamd.dll EXPORTS amd_order amd_defaults amd_control amd_info amd_2 amd_l_order amd_l_defaults amd_l_control amd_l_info amd_l2 Might this be useful information? Ben ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel