On Apr 12, 2008, at 12:35 AM, Jean-François Mertens wrote:
>
> On 12 Apr 2008, at 05:26, Jean-François Mertens wrote:
>>
>> On 12 Apr 2008, at 05:05, Ben Abbott wrote:
>>> With regards to "--all" ... do you mean that all the .o files
>>> included
>>> in the static lib are not to be included in the dylib? ... or
>>> something else?
>>
>> "-all_load" is a flag you can add to a link command, and that will
>> cause ALL .a archives in the final link line sent to ld to be fully
>> loaded, rather than just scanned for missing symbols, and loading
>> the corresponding code. The drawback is that it's effect cannot be
>> stopped,
>> so applies even to whatever '.a' file may be added by the "compiler"
>> (aka, ld interface) to the link command
>>
>> But all the .o files in your static lib should be included in your
>> dylib, right !
>> The above was just to tell you to keep, as you are doing now,
>> extracting
>> explicitly the .o files from the archives, and linking those into a
>> dylib,
>> rather than using the unsafe shortcut in atlas.info..
>>
>> Jean-Francois
>>
>> PS: But you should look at `man ld` before embarking on such a
>> thing ...
>
>
> Forgot to say: for suitesparse, you use only one compiler ("gcc"),
> if I
> remember correctly; so simplest is to link (as you were doing) using
> "gcc"
> as linker, and not to go back to ld (and hence have to add files on
> the link
> line that gcc (as linker) would anyway add..). So there was no
> suggestion
> above to try to imitate those aspects in alas.info)
>
> JF
JF, as you contributed significantly to the original SuiteSparse.info,
and have been involved in solving compiler problems respecting Octave,
I think you are a good choice for me to lean on :-)
On Fedora Linux, shared versions of the libraries are created directly
from the original object files. For example, from
http://article.gmane.org/gmane.os.apple.fink.devel/16135
make CFLAGS="$RPM_OPT_FLAGS -fPIC"
gcc -shared -Wl,-soname,libamd.so.%{amd_version_major} -o ../Lib/
libamd.so.%{amd_version} `ls *.o`
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.
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?
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).
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.
I also have questions regarding "Shlibs entry", and "SplitOffs", but
those will wait until I have a sufficient understanding so that I can
ask proper questions and understand the answers ... meaning I have
some studying to do! ;-)
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
