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 ------------------------------------------------------------------------- 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
