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

Reply via email to