Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
On 13 Apr 2008, at 18:07, Ben Abbott wrote: > >> >> sure _ very useful to build a correct lib. >> removing their first 2 lines via sed turns them into and pre-pending >> underscores exported symbols lists. >> > Forgive my ignorance, but how would I make use of these files to > produce a correct lib? As I told you, `man ld` is your friend ... :) It will tell you how to use such an exported symbols list. (you may also look at other pkgs, e.g., lpsolve.info, where such a def file is transformed by a sed command into an exported symbols list.. 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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
On Apr 13, 2008, at 11:45 AM, Jean-François Mertens wrote: > > On 13 Apr 2008, at 17:15, Ben Abbott wrote: >> 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? > > sure _ very useful to build a correct lib. > removing their first 2 lines via sed turns them into and pre-pending > underscores exported symbols lists. > > JF Forgive my ignorance, but how would I make use of these files to produce a correct lib? 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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
On 13 Apr 2008, at 17:45, Jean-François Mertens wrote: > > sure _ very useful to build a correct lib. > removing their first 2 lines and pre-pending underscores > via sed turns them into exported symbols lists. 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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
On 13 Apr 2008, at 17:15, Ben Abbott wrote: > 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? sure _ very useful to build a correct lib. removing their first 2 lines via sed turns them into exported symbols lists. 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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
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 l
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
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 _
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
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
-
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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
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 ... - 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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
On Apr 11, 2008, at 10:46 PM, Jean-François Mertens wrote: > > On 12 Apr 2008, at 04:31, Ben Abbott wrote: >> >> When I tried to create the dylib version for cholmod, I encountered >> an >> "unidentified symbol" error for those symbols that are in other >> libraries, cholmod for example. >> >> How do I tell gcc to ignore the missing symbols? > > DON'T ! > > It is very important that all symbols are identified (in the output > of "nm -m" , all undefined things should have a "from ..." > > You have the build the dylibs in dependency order, and link > explicitly with all those on which you depend .. > (and please no more..!) > > Cf any pkg for how dylib's are built; or, since you may be > more familiar with it, look at atlas.info, where they are built > "by hand" from the static archives, as you want to do, > since that seemed simpler than adapting the (experimental) > makefile. > But do not us the --all_load thing, it is better to explicitly extract > the .o files you want from the archives (there is no way to stop > the effect of '--all_load', so it would also apply to .a files that > are > added to the link line by gcc or whatever compiler). > > But please do look at `man ld` ! > > Jean-Francoia This is becoming quite a "learning experience" for me ;-) I'll take a look at the atlas package. 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? In either event, can you clarify (I likely in over my head). 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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
On 12 Apr 2008, at 04:31, Ben Abbott wrote: > > When I tried to create the dylib version for cholmod, I encountered an > "unidentified symbol" error for those symbols that are in other > libraries, cholmod for example. > > How do I tell gcc to ignore the missing symbols? DON'T ! It is very important that all symbols are identified (in the output of "nm -m" , all undefined things should have a "from ..." You have the build the dylibs in dependency order, and link explicitly with all those on which you depend .. (and please no more..!) Cf any pkg for how dylib's are built; or, since you may be more familiar with it, look at atlas.info, where they are built "by hand" from the static archives, as you want to do, since that seemed simpler than adapting the (experimental) makefile. But do not us the --all_load thing, it is better to explicitly extract the .o files you want from the archives (there is no way to stop the effect of '--all_load', so it would also apply to .a files that are added to the link line by gcc or whatever compiler). But please do look at `man ld` ! Jean-Francoia - 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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
Ben Abbott wrote: > On Apr 10, 2008, at 9:54 PM, Peter O'Gorman wrote: >> Ok, I guess that you will be doing this as part of the install >> phase, so: >> >> gcc -o %i/lib/libamd.0.dylib -dynamiclib \ >> -install_name %p/lib/libamd.0.dylib *.o > > When I tried to create the dylib version for cholmod, I encountered an > "unidentified symbol" error for those symbols that are in other > libraries, cholmod for example. > > How do I tell gcc to ignore the missing symbols? -undefined dynamic_lookup Peter -- Peter O'Gorman http://pogma.com - 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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
On Apr 10, 2008, at 9:54 PM, Peter O'Gorman wrote: > > Ok, I guess that you will be doing this as part of the install > phase, so: > > gcc -o %i/lib/libamd.0.dylib -dynamiclib \ > -install_name %p/lib/libamd.0.dylib *.o When I tried to create the dylib version for cholmod, I encountered an "unidentified symbol" error for those symbols that are in other libraries, cholmod for example. How do I tell gcc to ignore the missing symbols? gcc -dynamiclib -install_name /sw/lib/libcholmod.0.dylib -o libcholmod. 0.dylib cholmod_aat.o cholmod_add.o cholmod_amd.o cholmod_analyze.o cholmod_band.o cholmod_camd.o cholmod_ccolamd.o cholmod_change_factor.o cholmod_check.o cholmod_colamd.o cholmod_common.o cholmod_complex.o cholmod_copy.o cholmod_csymamd.o cholmod_dense.o cholmod_drop.o cholmod_error.o cholmod_etree.o cholmod_factor.o cholmod_factorize.o cholmod_horzcat.o cholmod_l_aat.o cholmod_l_add.o cholmod_l_amd.o cholmod_l_analyze.o cholmod_l_band.o cholmod_l_camd.o cholmod_l_ccolamd.o cholmod_l_change_factor.o cholmod_l_check.o cholmod_l_colamd.o cholmod_l_common.o cholmod_l_complex.o cholmod_l_copy.o cholmod_l_csymamd.o cholmod_l_dense.o cholmod_l_drop.o cholmod_l_error.o cholmod_l_etree.o cholmod_l_factor.o cholmod_l_factorize.o cholmod_l_horzcat.o cholmod_l_memory.o cholmod_l_metis.o cholmod_l_nesdis.o cholmod_l_norm.o cholmod_l_postorder.o cholmod_l_rcond.o cholmod_l_read.o cholmod_l_resymbol.o cholmod_l_rowadd.o cholmod_l_rowcolcounts.o cholmod_l_rowdel.o cholmod_l_rowfac.o cholmod_l_scale.o cholmod_l_sdmult.o cholmod_l_solve.o cholmod_l_sparse.o cholmod_l_spsolve.o cholmod_l_ssmult.o cholmod_l_submatrix.o cholmod_l_super_numeric.o cholmod_l_super_solve.o cholmod_l_super_symbolic.o cholmod_l_symmetry.o cholmod_l_transpose.o cholmod_l_triplet.o cholmod_l_updown.o cholmod_l_vertcat.o cholmod_l_write.o cholmod_memory.o cholmod_metis.o cholmod_nesdis.o cholmod_norm.o cholmod_postorder.o cholmod_rcond.o cholmod_read.o cholmod_resymbol.o cholmod_rowadd.o cholmod_rowcolcounts.o cholmod_rowdel.o cholmod_rowfac.o cholmod_scale.o cholmod_sdmult.o cholmod_solve.o cholmod_sparse.o cholmod_spsolve.o cholmod_ssmult.o cholmod_submatrix.o cholmod_super_numeric.o cholmod_super_solve.o cholmod_super_symbolic.o cholmod_symmetry.o cholmod_transpose.o cholmod_triplet.o cholmod_updown.o cholmod_vertcat.o cholmod_write.o Undefined symbols: "_colamd_set_defaults", referenced from: _cholmod_colamd in cholmod_colamd.o "_dtrsm_", referenced from: _cholmod_l_super_numeric in cholmod_l_super_numeric.o _cholmod_l_super_lsolve in cholmod_l_super_solve.o _cholmod_l_super_ltsolve in cholmod_l_super_solve.o _cholmod_super_numeric in cholmod_super_numeric.o _cholmod_super_lsolve in cholmod_super_solve.o _cholmod_super_ltsolve in cholmod_super_solve.o [... snip ...] 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
[Fink-devel] Q: convert lib*.a to lib*.dylib
The SuiteSparse package for Fedora linux appears to be built with the
following specfile...
Name: suitesparse
Version:3.0.0
Release:1%{?dist}
Summary:A collection of sparse matrix libraries
Group: System Environment/Libraries
License:Distributable
URL:http://www.cise.ufl.edu/research/sparse/SuiteSparse
Source0:
http://www.cise.ufl.edu/research/sparse/SuiteSparse/SuiteSparse-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: blas-devel
Obsoletes: umfpack
Obsoletes: ufsparse <= 2.1.1
Provides: ufsparse = %{version}-%{release}
%description
suitesparse is a collection of libraries for computations involving sparse
matrices. The package includes the following libraries:
AMD approximate minimum degree ordering
BTF permutation to block triangular form (beta)
CAMDconstrained approximate minimum degree ordering
COLAMD column approximate minimum degree ordering
CCOLAMD constrained column approximate minimum degree ordering
CHOLMOD sparse Cholesky factorization
CSparse a concise sparse matrix package
CXSparseCSparse extended: complex matrix, int and long int support
KLU sparse LU factorization, primarily for circuit simulation
LDL a simple LDL' factorization
UMFPACK sparse LU factorization
UFconfigconfiguration file for all the above packages.
%package devel
Summary:Development headers for SuiteSparse
Group: Development/Libraries
Requires: %{name} = %{version}-%{release}
Obsoletes: umfpack-devel
Obsoletes: ufsparse-devel <= 2.1.1
Provides: ufsparse-devel = %{version}-%{release}
%description devel
The suitesparse-devel package contains files needed for developing
applications which use the suitesparse libraries.
%package static
Summary:Static version of SuiteSparse libraries
Group: Development/Libraries
Requires: %{name}-devel = %{version}-%{release}
Provides: ufsparse-static = %{version}-%{release}
%description static
The suitesparse-static package contains the statically linkable
version of the suitesparse libraries.
%prep
%setup -q -n SuiteSparse
%build
%define amd_version 2.2
%define amd_version_major 2
%define btf_version 1.0
%define btf_version_major 1
%define camd_version 2.2
%define camd_version_major 2
%define ccolamd_version 2.7
%define ccolamd_version_major 2
%define cholmod_version 1.5
%define cholmod_version_major 1
%define colamd_version 2.7
%define colamd_version_major 2
%define csparse_version 2.2.0
%define csparse_version_major 2
%define cxsparse_version 2.2.0
%define cxsparse_version_major 2
%define klu_version 1.0
%define klu_version_major 1
%define ldl_version 2.0
%define ldl_version_major 2
%define umfpack_version 5.0.2
%define umfpack_version_major 5
### CHOLMOD can also be compiled to use the METIS library, but it is not
### used here because its licensing terms exclude it from Fedora Extras.
### To compile with METIS, define enable_metis as 1 below.
%define enable_metis 0
### CXSparse is a superset of CSparse, and the two share common header
### names, so it does not make sense to build both. CXSparse is built
### by default, but CSparse can be built instead by defining
### enable_csparse as 1 below.
%define enable_csparse 0
mkdir Devel Devel/AMD Devel/CHOLMOD Devel/KLU Devel/LDL Devel/UMFPACK \
Doc Doc/AMD Doc/BTF Doc/CAMD Doc/CCOLAMD Doc/CHOLMOD Doc/COLAMD \
Doc/KLU Doc/LDL Doc/UMFPACK Lib Include
pushd AMD
pushd Lib
make CFLAGS="$RPM_OPT_FLAGS -fPIC"
gcc -shared -Wl,-soname,libamd.so.%{amd_version_major} -o
../Lib/libamd.so.%{amd_version} `ls *.o`
popd
cp Lib/*.a Lib/*.so* ../Lib
cp Include/*.h ../Include
cp README.txt Doc/License Doc/ChangeLog ../Doc/AMD
cp Doc/*.pdf ../Devel/AMD
popd
pushd BTF
pushd Lib
make CFLAGS="$RPM_OPT_FLAGS -fPIC"
gcc -shared -Wl,-soname,libbtf.so.%{btf_version_major} -o
libbtf.so.%{btf_version} `ls *.o`
popd
cp Lib/*.a Lib/*.so* ../Lib
cp Include/*.h ../Include
cp README.txt Doc/* ../Doc/BTF
popd
pushd CAMD
pushd Lib
make CFLAGS="$RPM_OPT_FLAGS -fPIC"
gcc -shared -Wl,-soname,libcamd.so.%{camd_version_major} -o
../Lib/libcamd.so.%{camd_version} `ls *.o`
popd
cp Lib/*.a Lib/*.so* ../Lib
cp Include/*.h ../Include
cp README.txt Doc/ChangeLog Doc/License ../Doc/CAMD
cp Doc/*.pdf ../Devel/CAMD
popd
pushd CCOLAMD
pushd Lib
make CFLAGS="$RPM_OPT_FLAGS -fPIC"
gcc -shared -Wl,-soname,libccolamd.so.%{ccolamd_version_major} -o
libccolamd.so.%{ccolamd_version} `ls *.o`
popd
cp Lib/*.a Lib/*.so* ../Lib
cp Include/*.h ../Include
cp README.txt Doc/* ../Doc/CCOLAMD
popd
pushd Lib
popd
%if "%{?enable_metis}" == "1"
CHOLMOD_FLAGS="$RPM_OPT_FLAGS -I%{_includedir}/metis -fPIC"
%else
CHOLMOD_FLAGS="$RPM_OPT_FLAGS -DNPARTITION -fPIC"
%endif
pushd CHOLMOD
pushd Lib
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
On Apr 10, 2008, at 9:54 PM, Peter O'Gorman wrote: > ln -s libamd.0.dylib %i/lib/libamd.dylib I've rarely used symbolic links, does the line imply that target (libamd.0.dylib) is expected to be in the same directory as the link (libamd.dylib). Second question, is it not necessary to "install -m 644" symbolic links? 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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
On Apr 10, 2008, at 9:54 PM, Peter O'Gorman wrote: > Ben Abbott wrote: >> >> On Apr 10, 2008, at 7:47 PM, Peter O'Gorman wrote: >>> Ben Abbott wrote: It is has been suggested that the SuiteSparse static libraries be converted to dynamic libraries instead. >>> >>> Why are they static? Are they shared libraries on other platforms? >>> Who >>> suggested the change? >> >> They are originally static because that developers of SuiteSparse >> choose >> to make them so. >> >> Alexander asked if they might be changed. >> Rather than attempt to modify the makefiles directly, I'd like to try to directly convert the static libraries to dynamic ones. My thought is to do something like # Extract the object files from the static library. ar -x libamd.a # Build the dynamic version of the library. gcc -dynamiclib -arch_only `/usr/bin/arch` -o libamd.dylib *.o >>> >>> Change to libamd.0.dylib and you would also want to add - >>> install_name >>> $libdir/libamd.0.dylib. Please use a symlink so that the package >>> can be >>> splitoff correctly into -dev and -shlibs packages. Are the objects >>> in >>> the static archive built with any options? Specifically -fast or >>> -mdynamic-no-pic? If so, this strategy will not work. >> >> Forgive my naivete, but do I have this right? >> >> # Extract the object files from the static library. >> ar -x libamd.a >> # Build the dynamic version of the library. >> gcc -dynamiclib -install_name $libdir/libamd.o.dylib -o libamd. >> 0.dylib *.o >> >> Also can you give me the explicit command needed for symlink part? > > Ok, I guess that you will be doing this as part of the install > phase, so: > > gcc -o %i/lib/libamd.0.dylib -dynamiclib \ > -install_name %p/lib/libamd.0.dylib *.o > > ln -s libamd.0.dylib %i/lib/libamd.dylib > > You will, of course, have to create a -shlibs splitoff in your .info > file. Thanks for the detail. I'm just learning shell scripts, but am hopeful I have what I need to do the job. 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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
Ben Abbott wrote: > > On Apr 10, 2008, at 7:47 PM, Peter O'Gorman wrote: >> Ben Abbott wrote: >>> It is has been suggested that the SuiteSparse static libraries be >>> converted to dynamic libraries instead. >> >> Why are they static? Are they shared libraries on other platforms? Who >> suggested the change? > > They are originally static because that developers of SuiteSparse choose > to make them so. > > Alexander asked if they might be changed. > >>> Rather than attempt to modify the makefiles directly, I'd like to >>> try to directly convert the static libraries to dynamic ones. >>> >>> My thought is to do something like >>> >>> # Extract the object files from the static library. >>> ar -x libamd.a >>> # Build the dynamic version of the library. >>> gcc -dynamiclib -arch_only `/usr/bin/arch` -o libamd.dylib *.o >> >> Change to libamd.0.dylib and you would also want to add -install_name >> $libdir/libamd.0.dylib. Please use a symlink so that the package can be >> splitoff correctly into -dev and -shlibs packages. Are the objects in >> the static archive built with any options? Specifically -fast or >> -mdynamic-no-pic? If so, this strategy will not work. > > Forgive my naivete, but do I have this right? > > # Extract the object files from the static library. > ar -x libamd.a > # Build the dynamic version of the library. > gcc -dynamiclib -install_name $libdir/libamd.o.dylib -o libamd.0.dylib *.o > > Also can you give me the explicit command needed for symlink part? Ok, I guess that you will be doing this as part of the install phase, so: gcc -o %i/lib/libamd.0.dylib -dynamiclib \ -install_name %p/lib/libamd.0.dylib *.o ln -s libamd.0.dylib %i/lib/libamd.dylib You will, of course, have to create a -shlibs splitoff in your .info file. None of this will be of any help for octave upgrade issues this time, but it should help for the next time (when you will have to check the library for ABI compatibility and decide if it needs to have a new install_name or a higher compatibility_version etc.). The only reason that you are being asked to do this is that octave takes forever + a few days to build, and having shared libraries would allow octave to remain at the same revision and not be rebuilt even if this one package is updated in an incompatible way. Peter -- Peter O'Gorman http://pogma.com - 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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
On Apr 10, 2008, at 7:47 PM, Peter O'Gorman wrote: > Ben Abbott wrote: >> It is has been suggested that the SuiteSparse static libraries be >> converted to dynamic libraries instead. > > Why are they static? Are they shared libraries on other platforms? Who > suggested the change? > >> They aren't static on Debian, at least: I suggested the change because this is a dependency for octave, and as it stands now every update to suitesparse forces an update to octave. That's a bit brutal. - 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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
On Apr 10, 2008, at 7:47 PM, Peter O'Gorman wrote: > Ben Abbott wrote: >> It is has been suggested that the SuiteSparse static libraries be >> converted to dynamic libraries instead. > > Why are they static? Are they shared libraries on other platforms? Who > suggested the change? They are originally static because that developers of SuiteSparse choose to make them so. Alexander asked if they might be changed. >> Rather than attempt to modify the makefiles directly, I'd like to >> try to directly convert the static libraries to dynamic ones. >> >> My thought is to do something like >> >> # Extract the object files from the static library. >> ar -x libamd.a >> # Build the dynamic version of the library. >> gcc -dynamiclib -arch_only `/usr/bin/arch` -o libamd.dylib *.o > > Change to libamd.0.dylib and you would also want to add -install_name > $libdir/libamd.0.dylib. Please use a symlink so that the package can > be > splitoff correctly into -dev and -shlibs packages. Are the objects in > the static archive built with any options? Specifically -fast or > -mdynamic-no-pic? If so, this strategy will not work. Forgive my naivete, but do I have this right? # Extract the object files from the static library. ar -x libamd.a # Build the dynamic version of the library. gcc -dynamiclib -install_name $libdir/libamd.o.dylib -o libamd.0.dylib *.o Also can you give me the explicit command needed for symlink part? Regarding "any options", it does not look like there are any. However, I haven't looked through all the detail. If you're so inclined, the tracker item is below http://sourceforge.net/tracker/index.php?func=detail&aid=1923649&group_id=17203&atid=414256 The source code can be downloaded here http://www.cise.ufl.edu/research/sparse/SuiteSparse/ >> I have no practical experience with building libraries, and thought >> it a good idea to inquire here. >> >> Can anyone tell me what options are needed, desired, >> recommended, etc? > > If they static library is fat, ar x will not work. If they are not > fat, > you do not need to add -arch_only. They are not fat. 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
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
Ben Abbott wrote: > It is has been suggested that the SuiteSparse static libraries be > converted to dynamic libraries instead. Why are they static? Are they shared libraries on other platforms? Who suggested the change? > > Rather than attempt to modify the makefiles directly, I'd like to > try to directly convert the static libraries to dynamic ones. > > My thought is to do something like > > # Extract the object files from the static library. > ar -x libamd.a > # Build the dynamic version of the library. > gcc -dynamiclib -arch_only `/usr/bin/arch` -o libamd.dylib *.o Change to libamd.0.dylib and you would also want to add -install_name $libdir/libamd.0.dylib. Please use a symlink so that the package can be splitoff correctly into -dev and -shlibs packages. Are the objects in the static archive built with any options? Specifically -fast or -mdynamic-no-pic? If so, this strategy will not work. > > I have no practical experience with building libraries, and thought > it a good idea to inquire here. > > Can anyone tell me what options are needed, desired, > recommended, etc? If they static library is fat, ar x will not work. If they are not fat, you do not need to add -arch_only. Peter -- Peter O'Gorman http://pogma.com - 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
[Fink-devel] Q: convert lib*.a to lib*.dylib
It is has been suggested that the SuiteSparse static libraries be converted to dynamic libraries instead. Rather than attempt to modify the makefiles directly, I'd like to try to directly convert the static libraries to dynamic ones. My thought is to do something like # Extract the object files from the static library. ar -x libamd.a # Build the dynamic version of the library. gcc -dynamiclib -arch_only `/usr/bin/arch` -o libamd.dylib *.o I have no practical experience with building libraries, and thought it a good idea to inquire here. Can anyone tell me what options are needed, desired, recommended, etc? TiA 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
