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] dvdreadN
On 12 Apr 2008, at 20:12, Alexander Hansen wrote: > > On Apr 12, 2008, at 12:24 PM, Alexander Hansen wrote: > >> I'm trying to validate a package whose build chain requires >> simultaneous installation of libdvdread3-shlibs and libdvd4-shlibs. > > Make that libdvdread4-shlibs. > >> >> This is impossible, because the packages conflict. Looking at the >> versions, libdvdread4 is newer than libdvdread3, so would it be OK to >> convert packages that depend on the former over to the latter? > > And libdvdread3 is a later version than libdvdread4. That should > teach me not to do email when I'm heading out the door. No problem; the issue is there... I can't install the more recent pkg _ even shlibs _, because of the conflict, and because other pkgs depend on the older (shlibs). And, as the pkgs are, the shlibs must confict, because the install_names are the same. Please, you had an excellent idea, let's get rid of this problem, and update all deps of the old one to the new one ! pkgs involved : > # fgrep -rI libdvdread4 /sw/fink/dists/unstable|egrep -v > 'libdvdread.*.info|CVS'|cut -f1 -d:|sort -u > /sw/fink/dists/unstable/main/finkinfo/gnome/gst-plugins-ugly-0.10.info > /sw/fink/dists/unstable/main/finkinfo/gnome/gst-plugins.info > /sw/fink/dists/unstable/main/finkinfo/libs/libdvdnav.info > /sw/fink/dists/unstable/main/finkinfo/sound/ogmtools.info > /sw/fink/dists/unstable/main/finkinfo/utils/dvdbackup.info > /sw/fink/dists/unstable/main/finkinfo/utils/transcode.info Thanks ! 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] dvdreadN
On Apr 12, 2008, at 12:24 PM, Alexander Hansen wrote: > I'm trying to validate a package whose build chain requires > simultaneous installation of libdvdread3-shlibs and libdvd4-shlibs. Make that libdvdread4-shlibs. > > This is impossible, because the packages conflict. Looking at the > versions, libdvdread4 is newer than libdvdread3, so would it be OK to > convert packages that depend on the former over to the latter? And libdvdread3 is a later version than libdvdread4. That should teach me not to do email when I'm heading out the door. - 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] dvdreadN
I'm trying to validate a package whose build chain requires simultaneous installation of libdvdread3-shlibs and libdvd4-shlibs. This is impossible, because the packages conflict. Looking at the versions, libdvdread4 is newer than libdvdread3, so would it be OK to convert packages that depend on the former over to the latter? - 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 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
