Obsolete Shared Libraries?
9.1 RC3 (started out as 9.0 RELEASE) Over time, as ports have been upgraded, I seem to have accumulated a number of obsolete shared libraries - a recent example being /usr/local/ lib/libpcre.so.1, which appears no longer to be linked in by anything, having been replaced by libpcre.so.3. Is there a convenient and safe utility to clean out this detritus? I'm not trying to save disk space or anything; it's just a matter of tidiness. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Obsolete Shared Libraries?
On Tue, 18 Dec 2012 12:40:39 + (UTC) Walter Hurry walterhu...@gmail.com wrote: 9.1 RC3 (started out as 9.0 RELEASE) Over time, as ports have been upgraded, I seem to have accumulated a number of obsolete shared libraries - a recent example being /usr/local/ lib/libpcre.so.1, which appears no longer to be linked in by anything, having been replaced by libpcre.so.3. Is there a convenient and safe utility to clean out this detritus? I'm not trying to save disk space or anything; it's just a matter of tidiness. portsclean - it will also tidy up distfiles, packages and work areas. -- Steve O'Hara-Smith st...@sohara.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
linking against shared libraries not in default path
I compiled some numerical libraries under my home directory, including static and shared libs. The shared lib is % ls ./src/libslatec.so.1 ./src/libslatec.so.1 % Now I'd like to test shared libraries, so I do % gfortran45 -o test01.x test01.o qc6a.o -L./src/ -lslatec % ./test01.x /libexec/ld-elf.so.1: Shared object libslatec.so.1 not found, required by test01.x % How can I tell the executable to look for a shared library in a specific directory? I tried setting LIBRARY_PATH, but it didn't help. Perhaps I completely misunderstand how shared libraries work.. Please advise many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: linking against shared libraries not in default path
On Mon, 29 Nov 2010, Anton Shterenlikht wrote: |I compiled some numerical libraries under my home |directory, including static and shared libs. The |shared lib is | |% ls ./src/libslatec.so.1 |./src/libslatec.so.1 |% | |Now I'd like to test shared libraries, so I do | |% gfortran45 -o test01.x test01.o qc6a.o -L./src/ -lslatec |% ./test01.x |/libexec/ld-elf.so.1: Shared object libslatec.so.1 not found, required by test01.x |% | |How can I tell the executable to look for a shared library |in a specific directory? I tried setting LIBRARY_PATH, but |it didn't help. | |Perhaps I completely misunderstand how shared libraries work.. | |Please advise | ldconfig -m ./src/libslatec.so.1 (in your example) +---+ ! CANMOS ISP Network! +---+ ! Best regards ! ! Igor V. Ruzanov, network operational staff! ! e-Mail: ig...@canmos.ru ! +---+ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: linking against shared libraries not in default path
On Mon, 29 Nov 2010, Anton Shterenlikht wrote: |I compiled some numerical libraries under my home |directory, including static and shared libs. The |shared lib is | |% ls ./src/libslatec.so.1 |./src/libslatec.so.1 |% | |Now I'd like to test shared libraries, so I do | |% gfortran45 -o test01.x test01.o qc6a.o -L./src/ -lslatec |% ./test01.x |/libexec/ld-elf.so.1: Shared object libslatec.so.1 not found, required by test01.x |% | |How can I tell the executable to look for a shared library |in a specific directory? I tried setting LIBRARY_PATH, but |it didn't help. | Ooops, sorry, you must give full path of shared object, *NOT* a file name: ldconfig -m ./src in your test example. +---+ ! CANMOS ISP Network! +---+ ! Best regards ! ! Igor V. Ruzanov, network operational staff! ! e-Mail: ig...@canmos.ru ! +---+ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: linking against shared libraries not in default path
On Monday 29 November 2010 14:50:59 Anton Shterenlikht wrote: I compiled some numerical libraries under my home directory, including static and shared libs. The shared lib is % ls ./src/libslatec.so.1 ./src/libslatec.so.1 % Now I'd like to test shared libraries, so I do % gfortran45 -o test01.x test01.o qc6a.o -L./src/ -lslatec % ./test01.x /libexec/ld-elf.so.1: Shared object libslatec.so.1 not found, required by test01.x % How can I tell the executable to look for a shared library in a specific directory? I tried setting LIBRARY_PATH, but it didn't help. The name of the variable is LD_LIBRARY_PATH. It is described in the rtld(1) manpage. You can also add it to the executable using -R as in: % gfortran45 -o test01.x test01.o qc6a.o -L./src/ -Rfull path -lslatec signature.asc Description: This is a digitally signed message part.
Re: linking against shared libraries not in default path
On Mon, Nov 29, 2010 at 03:00:45PM +0100, Tijl Coosemans wrote: On Monday 29 November 2010 14:50:59 Anton Shterenlikht wrote: I compiled some numerical libraries under my home directory, including static and shared libs. The shared lib is % ls ./src/libslatec.so.1 ./src/libslatec.so.1 % Now I'd like to test shared libraries, so I do % gfortran45 -o test01.x test01.o qc6a.o -L./src/ -lslatec % ./test01.x /libexec/ld-elf.so.1: Shared object libslatec.so.1 not found, required by test01.x % How can I tell the executable to look for a shared library in a specific directory? I tried setting LIBRARY_PATH, but it didn't help. The name of the variable is LD_LIBRARY_PATH. It is described in the rtld(1) manpage. You can also add it to the executable using -R as in: % gfortran45 -o test01.x test01.o qc6a.o -L./src/ -Rfull path -lslatec Tijl, thank you. Both options work for me on amd64 and ia64. thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Speeding up (caching?) shared libraries loading
Hello. Suppose I have an executable which I need to invoke repeatedly (e.g. to run tests in a makefile). This executables spend most of its time loading (rather than processing), due to the need of several huge shared libraries. I'd welcome an hint on how to speed this up. Possible thing would be to cache these shared libraries (and possibily the executable too) in memory, so that any invocation after the first is faster. Is this possible at all? Any other idea? bye Thanks av. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Speeding up (caching?) shared libraries loading
On Tue Aug 31 10, Andrea Venturoli wrote: Hello. Suppose I have an executable which I need to invoke repeatedly (e.g. to run tests in a makefile). This executables spend most of its time loading (rather than processing), due to the need of several huge shared libraries. I'd welcome an hint on how to speed this up. Possible thing would be to cache these shared libraries (and possibily the executable too) in memory, so that any invocation after the first is faster. Is this possible at all? Any other idea? i don't think there's an out-of-the-box solution. have you checked out ports to see if there's something there which might do what you're looking for? another possibility would be to use tmpfs and store the files and libraries on a memory based partition. you could write a script which would copy files/libs to the tmpfs partition during boot time e.g. cheers. alex bye Thanks av. -- a13x ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Speeding up (caching?) shared libraries loading
On 08/31/10 14:44, Andrea Venturoli wrote: Hello. Suppose I have an executable which I need to invoke repeatedly (e.g. to run tests in a makefile). This executables spend most of its time loading (rather than processing), due to the need of several huge shared libraries. I'd welcome an hint on how to speed this up. Possible thing would be to cache these shared libraries (and possibily the executable too) in memory, so that any invocation after the first is faster. Is this possible at all? Normal file system caching will cover this case (unless you have very little memory available). The only other thing you might do to speed this up is prebinding / prelinking but if you are often rebuilding the project it might not help. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Speeding up (caching?) shared libraries loading
Ivan Voras wrote: On 08/31/10 14:44, Andrea Venturoli wrote: Hello. Suppose I have an executable which I need to invoke repeatedly (e.g. to run tests in a makefile). This executables spend most of its time loading (rather than processing), due to the need of several huge shared libraries. I'd welcome an hint on how to speed this up. Possible thing would be to cache these shared libraries (and possibily the executable too) in memory, so that any invocation after the first is faster. Is this possible at all? Normal file system caching will cover this case (unless you have very little memory available). The only other thing you might do to speed this up is prebinding / prelinking but if you are often rebuilding the project it might not help. With the PathScale compiler we tightly integrate hugetblfs support on linux. (At some point we'll likely adapt this approach to work with FBSD superpages) It can provide significant speed-up in some cases. (Like the initial loading of Firefox and some SPEC benchmarks) I would give that a try and see what sort of results you get.. (Not exactly what you were asking about, but could help) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Speeding up (caching?) shared libraries loading
In the last episode (Aug 31), Andrea Venturoli said: Suppose I have an executable which I need to invoke repeatedly (e.g. to run tests in a makefile). This executables spend most of its time loading (rather than processing), due to the need of several huge shared libraries. Link your program statically and bypass the dynamic linker completely. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Speeding up (caching?) shared libraries loading
Il 08/31/10 16:35, Dan Nelson ha scritto: In the last episode (Aug 31), Andrea Venturoli said: Suppose I have an executable which I need to invoke repeatedly (e.g. to run tests in a makefile). This executables spend most of its time loading (rather than processing), due to the need of several huge shared libraries. Link your program statically and bypass the dynamic linker completely. Then my binary would be more than 200MB and it wouldn't load that fast either. Besides I have several binaries using the same libraries and linking them all statically would take up a lot more time. bye Thanks anyway av. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
cups - error while loading shared libraries: /usr/lib/libcups.so.2: ELF file OS ABI invalid
Hello fellas, I have a 8.0-RELEASE (i386) with the following make.conf: PERL_VERSION=5.8.9 WRKDIRPREFIX=/wrkdir NO_BIND = YES WITH_CUPS=YES CUPS_OVERWRITE_BASE=YES WITHOUT_LPR=YES and a custom kernel that has all the features of GENERIC + all required stuff for pf. Nothig special up to this point. I needed to install cups on this particular machine because the network it resides on has several printers. There is 1 network printer which I added without any problems but I also need to add a Samsung CLP-310_Series USB printer. cups-base-1.4.4 cups-client-1.4.4 cups-image-1.4.4 cups-pstoraster-8.15.4_6 gutenprint-cups-5.2.4_2 gutenprint-base-5.2.4_2 gutenprint-cups-5.2.4_2 and devfs.rules: [system=10] add path 'unlpt*' mode 0660 group cups add path 'ulpt*' mode 0660 group cups add path 'lpt*' mode 0660 group cups add path 'usb/4.2.0' mode 0660 group cups - this was added because cups did not see/detect my usb printer and after a restart of devfs and cups, I was able to add the Samsung printer (ppd was on the CD). All fine and dandy up to this point but when I tried to print a test page I got: [...] D [28/Aug/2010:11:44:14 +0300] [Job 29] Samsung_CLP-310_Series: error while loading shared libraries: /usr/lib/libcups.so.2: ELF file OS ABI invalid [...] D [28/Aug/2010:11:44:14 +0300] [Job 29] printer-state-message=/usr/local/libexec/cups/filter/rastertosamsungsplc failed [...] So I have 2 problems. 1) /usr/lib/libcups.so.2 # ldd /usr/lib/libcups.so.2 /usr/lib/libcups.so.2: libm.so.5 = /lib/libm.so.5 (0x2830) libcrypt.so.5 = /lib/libcrypt.so.5 (0x2831a000) libz.so.5 = /lib/libz.so.5 (0x281ee000) libthr.so.3 = /lib/libthr.so.3 (0x28333000) libc.so.7 = /lib/libc.so.7 (0x28091000) 2) rastertosamsungsplc As far as problem 2 goes, I am guessing the file has some problems (although it worked on a centos with the same printer - wtf ? - or maybe it is some linux version of the file) I have the linux kernel module loaded and linux_base-f10-10_2 installed My guess is that cups needs a linux version of libcups.so.2 and not a native BSD one. This would explain the fact that it cannot find the file in the first place. I searched for libcups.so.2 and the only place I could find it was in /usr/lib which means that this file is a BSD file. If anyone can pass my their libcups.so.2 to try I would appreciate it (linux and/or BSD version - if one) . Any ideas and/or thought are highly welcomed -- Best regards, Claudiu Vasadi ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Compiling only shared libraries?
On Mon, Dec 21, 2009 at 03:00:27PM -0800, Matthew Fleming wrote: We have a bunch of libraries to support our product and as far as I know we only link to the shared library version. I'd like to skip the build of the static version of our libraries to speed up our builds and save on disk space, but I don't see any way to do that via directives in the Makefiles. I didn't see anything in bsd.lib.mk which would indicate this can be done. Is this even possible? Just write your own Makefile. See the snippets below; BASENAME = foo VERSION_MAJOR = 1 VERSION_MINOR = 0 ... OBJS = bar.o baz.o ... ... SHARED= lib$(BASENAME).so.$(VERSION_MAJOR).$(VERSION_MINOR) ... # build the shared library $(SHARED): $(OBJS) cc -shared -Wl,-soname,lib$(BASENAME).so.$(VERSION_MAJOR) \ -o $(SHARED) $(OBJS) $(LIBS) strip -g --strip-unneeded $(SHARED) Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpr4nw699mKZ.pgp Description: PGP signature
Compiling only shared libraries?
We have a bunch of libraries to support our product and as far as I know we only link to the shared library version. I'd like to skip the build of the static version of our libraries to speed up our builds and save on disk space, but I don't see any way to do that via directives in the Makefiles. I didn't see anything in bsd.lib.mk which would indicate this can be done. Is this even possible? (I am not subscribed to -questions, so please cc: me on responses). Thanks, matthew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: 2 problems with shared libraries
On Thu, 24 May 2007 12:26:47 +0700 (ICT) Olivier Nicole wrote: $ ldconfig -r | grep libqt-mt.so.3 102:-lqt-mt.3 = /usr/X11R6/lib/libqt-mt.so.3 $ ldd colorseg colorseg: libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0x28279000) libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0x282e2000) libpng.so.3 = /usr/lib/libpng.so.3 (0x2830) libdpstk.so.1 = /usr/X11R6/lib/libdpstk.so.1 (0x28323000) libdps.so.1 = /usr/X11R6/lib/libdps.so.1 (0x2832b000) libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x28374000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x283c7000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x283d7000) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x283e) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x283f8000) libz.so.1 = /usr/lib/libz.so.1 (0x284f4000) libpthread.so.0 = /lib/obsolete/linuxthreads/libpthread.so.0 (0x28507000) libqt-mt.so.3 = not found libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0x2855b000) libm.so.6 = /lib/obsolete/linuxthreads/libm.so.6 (0x28614000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2863a000) libc.so.6 = /lib/obsolete/linuxthreads/libc.so.6 (0x28644000) libdl.so.2 = /lib/libdl.so.2 (0x28763000) /lib/ld-linux.so.2 (0x2825a000) Why libqt-mt.so.3 is not found while it is listed by ldconfig? Colorseg is a Linux executable that I got without source. Those libraries have (an undisplayed) prefix /compat/linux. And there is no /compat/linux/usr/X11R6/lib/libqt-mt.so.3. This library is from qt3 rpm which we don't have currently at out ports tree. However you may try to install the port I wrote: ftp://ftp.ipt.ru/pub/download/linux-qt3.tar.bz2 # cp linux-qt3.tar.bz2 /usr/ports/x11-toolkits # cd /usr/ports/x11-toolkits # tar xyf linux-qt3.tar.bz2 # cd linux-qt3 # make install clean I've tested the port at tinderbox (build/install/deinstall) but can't test at run time -- there may be missed dependencies (though I hope it shouldn't happen). Any feedback is appreciated. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 problems with shared libraries
Hi Boris, However you may try to install the port I wrote: ftp://ftp.ipt.ru/pub/download/linux-qt3.tar.bz2 # cp linux-qt3.tar.bz2 /usr/ports/x11-toolkits # cd /usr/ports/x11-toolkits # tar xyf linux-qt3.tar.bz2 # cd linux-qt3 # make install clean I've tested the port at tinderbox (build/install/deinstall) but can't test at run time -- there may be missed dependencies (though I hope it shouldn't happen). Any feedback is appreciated. It looks like it is working: the software now is doing what it is supposed to do! Means that the port of the library should be good. Thanks a lot, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 problems with shared libraries
Hi Oliver, On Fri, 25 May 2007 09:23:11 +0700 (ICT) Olivier Nicole wrote: However you may try to install the port I wrote: ftp://ftp.ipt.ru/pub/download/linux-qt3.tar.bz2 # cp linux-qt3.tar.bz2 /usr/ports/x11-toolkits # cd /usr/ports/x11-toolkits # tar xyf linux-qt3.tar.bz2 # cd linux-qt3 # make install clean I've tested the port at tinderbox (build/install/deinstall) but can't test at run time -- there may be missed dependencies (though I hope it shouldn't happen). Any feedback is appreciated. It looks like it is working: the software now is doing what it is supposed to do! Means that the port of the library should be good. Great, I'll commit the port when the ports tree is unfrozen. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
2 problems with shared libraries
Hi, I have the two following problems: 1) $ ldconfig -r | grep libqt-mt.so.3 102:-lqt-mt.3 = /usr/X11R6/lib/libqt-mt.so.3 $ ldd colorseg colorseg: libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0x28279000) libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0x282e2000) libpng.so.3 = /usr/lib/libpng.so.3 (0x2830) libdpstk.so.1 = /usr/X11R6/lib/libdpstk.so.1 (0x28323000) libdps.so.1 = /usr/X11R6/lib/libdps.so.1 (0x2832b000) libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x28374000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x283c7000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x283d7000) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x283e) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x283f8000) libz.so.1 = /usr/lib/libz.so.1 (0x284f4000) libpthread.so.0 = /lib/obsolete/linuxthreads/libpthread.so.0 (0x28507000) libqt-mt.so.3 = not found libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0x2855b000) libm.so.6 = /lib/obsolete/linuxthreads/libm.so.6 (0x28614000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2863a000) libc.so.6 = /lib/obsolete/linuxthreads/libc.so.6 (0x28644000) libdl.so.2 = /lib/libdl.so.2 (0x28763000) /lib/ld-linux.so.2 (0x2825a000) Why libqt-mt.so.3 is not found while it is listed by ldconfig? Colorseg is a Linux executable that I got without source. 2nd question: while playing around with ldconfig, I think I erased the list of directories that are used to find the shared lib. Is there a way to reconstruct this list of directories? Or I should grab my backup and restore /var/run/ld-elf.so.hints? best regards, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
howto convert Linux shared libraries foo.so to FreeBSD shared libraries
Does anybody know how to convert a shared object compiled in Linux foo-linux.so to a shared object compiled for FreeBSD freebsd-foo.so? I mean a freebsd-foo.so to which I can link with objects compiled by a native FreeBSD compiler. Or equivalently how to create a FreeBSD foo.so from a linux foo.so which would be identical to that which would be compiled from source in FreeBSD? I do not need to run a Linux binary. What I need to do is to link my object (.o) files compiled natively in FreeBSD with a foo.so which is a linux library. Thanks in advance! Simeon. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: howto convert Linux shared libraries foo.so to FreeBSD shared libraries
In the last episode (Jun 24), Simeon Nifos said: Does anybody know how to convert a shared object compiled in Linux foo-linux.so to a shared object compiled for FreeBSD freebsd-foo.so? I mean a freebsd-foo.so to which I can link with objects compiled by a native FreeBSD compiler. Or equivalently how to create a FreeBSD foo.so from a linux foo.so which would be identical to that which would be compiled from source in FreeBSD? I don't think either of these are possible because internal library structures (the size of off_t, or the field sizes and ordering of struct stat or FILE, for example) are different. Any converter would have to decompile the code into C (impossible in practice) and recompile it at a FreeBSD binary. I do not need to run a Linux binary. What I need to do is to link my object (.o) files compiled natively in FreeBSD with a foo.so which is a linux library. Take a look at the www/linuxpluginwrapper port, which creates wrapper libraries that convert Linux function calls to FreeBSD ones. You then use libmap.conf to substitute these libraries for any ones called by the Linux shared library. Depending on what your library's API looks like, and what external functions it calls, you might be able to get it to work. The correct solution would be to ask your vendor for either a FreeBSD shared library, or the source :) -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: conver Linux shared libraries foo.so to FreeBSD shared libraries
2006/6/20, Simeon Nifos [EMAIL PROTECTED]: Does anybody know how to convert a shared object compiled in Linux foo-linux.so to a shared object compiled for FreeBSD freebsd-foo.so? I mean a freebsd-foo.so to which I can link with objects compiled by a native FreeBSD compiler. Or equivalently how to create a FreeBSD foo.so from a linux foo.so which would be identical to that which would be compiled from source in FreeBSD? Thanks in advance! Simeon. - Want to be your own boss? Learn how on Yahoo! Small Business. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] You are probably just needing to read about the linux-base, you can run linux softwares there, you don't need to convert anything. cd /usr/ports/emulators/linux_base-fc4 Don't forget to add at your fstab: linproc /compat/linux/proc linprocfs rw 0 0 Anytime you need to run a linux software use to linux-base. Hugo Pessoa/NgD Vulto. -- [Freebsd User Group] Fug-Br/BsD-Ce proud active member. There will be a day machines will reign, and only the ones able to understand them will survive. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
conver Linux shared libraries foo.so to FreeBSD shared libraries
Does anybody know how to convert a shared object compiled in Linux foo-linux.so to a shared object compiled for FreeBSD freebsd-foo.so? I mean a freebsd-foo.so to which I can link with objects compiled by a native FreeBSD compiler. Or equivalently how to create a FreeBSD foo.so from a linux foo.so which would be identical to that which would be compiled from source in FreeBSD? Thanks in advance! Simeon. - Want to be your own boss? Learn how on Yahoo! Small Business. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
error while loading shared libraries: libX11.so.6
I recently upgraded to 6.1 beta3, and am now having a problem with Realplayer. When I try to start it from the command line, I get the following: # realplay /usr/X11R6/lib/RealPlayer/realplay.bin: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory I googled, but there does not seem to be a fix. Any suggestions for fixing are appreciated. TIA ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: error while loading shared libraries: libX11.so.6
On Thu, Mar 16, 2006 at 03:16:57AM -0500, [EMAIL PROTECTED] wrote: I recently upgraded to 6.1 beta3, and am now having a problem with Realplayer. When I try to start it from the command line, I get the following: # realplay /usr/X11R6/lib/RealPlayer/realplay.bin: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory I googled, but there does not seem to be a fix. Any suggestions for fixing are appreciated. Sounds like you're missing the relevant linux package. Did you install realplayer from the package? It should have taken care of this. Kris pgpdsOExc0nHQ.pgp Description: PGP signature
Making shared libraries findable ...
I have some shared libraries blah.so etc. that I want to be available to other programs. They are located in a separate directory from the default linux compat stuff. I guess I could create a link using ln -s, but every time blah.so is rebuilt the link will not longer be valid. What's the standard way of taking care of this? Thanks alot in advance. -- Kiffin Gish [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Preloading of shared libraries
On Mon, Oct 24, 2005 at 07:13:25PM +0200, Philip Lykke Carlsen wrote: Sunday 23 October 2005 18:23 skrev du: Philip Lykke Carlsen wrote: Hey.. I wondered if it was possible to load a selection of shared libraies into the cache at boot time.. I figure that it would speed up starting things.. like the KDE login manager for instance.. hm.. is this possible? .. and if so.. would it speed up the process of starting stuff at all?.. Sort of. At one point, you could set the sticky bit on files as a hint to the pager to try and keep them in memory, which was intended for things like /bin/sh, cron, login, and maybe libc. aah.. I always wondered what the sticky bit actually did.. See sticky(8). It doesn't do any longer what the previous poster said. Kris pgpDa1XQoRPaq.pgp Description: PGP signature
Re: Preloading of shared libraries
Sunday 23 October 2005 18:23 skrev du: Philip Lykke Carlsen wrote: Hey.. I wondered if it was possible to load a selection of shared libraies into the cache at boot time.. I figure that it would speed up starting things.. like the KDE login manager for instance.. hm.. is this possible? .. and if so.. would it speed up the process of starting stuff at all?.. Sort of. At one point, you could set the sticky bit on files as a hint to the pager to try and keep them in memory, which was intended for things like /bin/sh, cron, login, and maybe libc. aah.. I always wondered what the sticky bit actually did.. Whether it would help in your particular case is harder to say, how much RAM does your machine have, and what kind of CPU? Some people believe that KDE requires excessive resources for what it does, consider fluxbox or something more lightweight... No problem when when it comes to resources.. ( I have an ordinary x86 2,6 GHz Celeron CPU and 768 mb DDR RAM ) I tried fluxbox once.. didn't like it though.. but that's just a matter of taste.. just thought I'd try KDE as a change as I've previously only used wm's like EvilWM, LWM, TWM an Co.. .. so, there isn't a program that doesn't do anything but load a shared object into memory and then close? .. hm.. if all it takes is to call open() for a sticky-bit file to stay in memory, I'd gladly write that program myself :-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Preloading of shared libraries
Hey.. I wondered if it was possible to load a selection of shared libraies into the cache at boot time.. I figure that it would speed up starting things.. like the KDE login manager for instance.. hm.. is this possible? .. and if so.. would it speed up the process of starting stuff at all?.. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Preloading of shared libraries
Philip Lykke Carlsen wrote: Hey.. I wondered if it was possible to load a selection of shared libraies into the cache at boot time.. I figure that it would speed up starting things.. like the KDE login manager for instance.. hm.. is this possible? .. and if so.. would it speed up the process of starting stuff at all?.. Sort of. At one point, you could set the sticky bit on files as a hint to the pager to try and keep them in memory, which was intended for things like /bin/sh, cron, login, and maybe libc. Whether it would help in your particular case is harder to say, how much RAM does your machine have, and what kind of CPU? Some people believe that KDE requires excessive resources for what it does, consider fluxbox or something more lightweight... -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
libgmodule-2 questions (and shared libraries in general)
On one of my two 4.11 boxes, kdelibs fails to build. Here's the output: snip gmake[3]: Entering directory `/usr/ports/x11/kdelibs3/work/kdelibs-3.4.0/arts/kde' /usr/local/bin/mcopidl -I/usr/local/include/arts -t -I. ../../arts/kde/artskde.idl /usr/libexec/ld-elf.so.1: Shared object libgmodule-2.0.so.400 not found, required by mcopidl snip A find produces: [EMAIL PROTECTED](p2)/root 102% find / -name libgmodule-2\* /usr/local/lib/compat/pkg/libgmodule-2.0.so.200 /usr/local/lib/libgmodule-2.0.so.600 /usr/local/lib/libgmodule-2.0.so /usr/local/lib/libgmodule-2.0.a /usr/compat/linux/usr/lib/libgmodule-2.0.so.0 /usr/compat/linux/usr/lib/libgmodule-2.0.so.0.200.1 I'm not sure I haven't shot myself in the foot, by using portsclean -L and libchk without knowing what I'm doing ... 8o) What can I do? -- FreeBSD 4.11-STABLE i386 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Where do the linker look for shared libraries?
Hi! I've tried to compile and link a small game written with the Allegro API. For some odd reason the linker just don't understand how to resolve the symbols in the library. It just can't accept that the library is in a .so file and not an .a archive, and even when I point it out explicitly it still don't get it. This is my commandline: gcc main.o rotoAction.o rotoCog.o -o RotoCube.exe -lstdc++ -L/usr/local/lib/ -lalleg and the errors I get looks like this: /usr/local/lib//liballeg.so: undefined reference to `_poly_zbuf_atex_trans8' /usr/local/lib//liballeg.so: undefined reference to `_poly_scanline_atex_mask_lit32' Which is kind of odd since before I added the -L flag it complained about the .a file being missing. Now it's not being used. How do ld decide where to look for libraries? Is there a way to teach it systemwide not to search for ar archived, and in fact use the .so files? And why on earth is the linker complaining about undefined references now that it is actually looking at the right shared library file? /Andreas -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where do the linker look for shared libraries?
In the last episode (Mar 02), Andreas Davour said: I've tried to compile and link a small game written with the Allegro API. For some odd reason the linker just don't understand how to resolve the symbols in the library. It just can't accept that the library is in a .so file and not an .a archive, and even when I point it out explicitly it still don't get it. This is my commandline: gcc main.o rotoAction.o rotoCog.o -o RotoCube.exe -lstdc++ -L/usr/local/lib/ -lalleg and the errors I get looks like this: /usr/local/lib//liballeg.so: undefined reference to `_poly_zbuf_atex_trans8' /usr/local/lib//liballeg.so: undefined reference to `_poly_scanline_atex_mask_lit32' This is the linker saying there are symbols in liballeg.so that I cannot find anywhere. Maybe you need to specify another library along with liballeg? Are you using the allegro port? -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where do the linker look for shared libraries?
On Wed, 2 Mar 2005, Dan Nelson wrote: In the last episode (Mar 02), Andreas Davour said: I've tried to compile and link a small game written with the Allegro API. For some odd reason the linker just don't understand how to resolve the symbols in the library. It just can't accept that the library is in a .so file and not an .a archive, and even when I point it out explicitly it still don't get it. This is my commandline: gcc main.o rotoAction.o rotoCog.o -o RotoCube.exe -lstdc++ -L/usr/local/lib/ -lalleg and the errors I get looks like this: /usr/local/lib//liballeg.so: undefined reference to `_poly_zbuf_atex_trans8' /usr/local/lib//liballeg.so: undefined reference to `_poly_scanline_atex_mask_lit32' This is the linker saying there are symbols in liballeg.so that I cannot find anywhere. Maybe you need to specify another library along with liballeg? Are you using the allegro port? I have grep'ed for those symbols and they come from liballeg.so, no place else. That's one of the very confusing things with those errors. I'm using the allegro port. BTW, there is a linux-allegro port as well. Why is this needed if Allegro is a platform independant API? /Andreas -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where do the linker look for shared libraries?
In the last episode (Mar 02), Andreas Davour said: On Wed, 2 Mar 2005, Dan Nelson wrote: In the last episode (Mar 02), Andreas Davour said: I've tried to compile and link a small game written with the Allegro API. For some odd reason the linker just don't understand how to resolve the symbols in the library. It just can't accept that the library is in a .so file and not an .a archive, and even when I point it out explicitly it still don't get it. This is my commandline: gcc main.o rotoAction.o rotoCog.o -o RotoCube.exe -lstdc++ -L/usr/local/lib/ -lalleg and the errors I get looks like this: /usr/local/lib//liballeg.so: undefined reference to `_poly_zbuf_atex_trans8' /usr/local/lib//liballeg.so: undefined reference to `_poly_scanline_atex_mask_lit32' This is the linker saying there are symbols in liballeg.so that I cannot find anywhere. Maybe you need to specify another library along with liballeg? Are you using the allegro port? I have grep'ed for those symbols and they come from liballeg.so, no place else. That's one of the very confusing things with those errors. A web search on undefined reference _poly_zbuf_atex_trans8 comes up with a couple hits, including a post that says you need to use the allegro-config command to determine the correct flags and libraries to link allegro. What does allegro-config --libs print? The demo programs built by the allegro port must work, so you could always build the port again and determine what flags it used. I'm using the allegro port. BTW, there is a linux-allegro port as well. Why is this needed if Allegro is a platform independant API? For linux programs that might need the library (same API, different ABI). I assume there's at least one in the ports tree somewhere. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where do the linker look for shared libraries?
On Wed, 2 Mar 2005, Dan Nelson wrote: and the errors I get looks like this: /usr/local/lib//liballeg.so: undefined reference to `_poly_zbuf_atex_trans8' /usr/local/lib//liballeg.so: undefined reference to `_poly_scanline_atex_mask_lit32' This is the linker saying there are symbols in liballeg.so that I cannot find anywhere. Maybe you need to specify another library along with liballeg? Are you using the allegro port? I have grep'ed for those symbols and they come from liballeg.so, no place else. That's one of the very confusing things with those errors. A web search on undefined reference _poly_zbuf_atex_trans8 comes up with a couple hits, including a post that says you need to use the allegro-config command to determine the correct flags and libraries to link allegro. What does allegro-config --libs print? The demo programs built by the allegro port must work, so you could always build the port again and determine what flags it used. Allegro have indeed changed since I looked at it last. I think it's time to check the pkg-plist. I didn't even think about Google! That did indeed fix the problems. I wasn't far off, but it had to link with a file with the unfriendly name unsharable. I'm using the allegro port. BTW, there is a linux-allegro port as well. Why is this needed if Allegro is a platform independant API? For linux programs that might need the library (same API, different ABI). I assume there's at least one in the ports tree somewhere. OK. Sounds strange, but I guess it makes sense. I still wonder if there's a way to have ld not go looking for ar archives by deafault... /Andreas -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
libtool/shared libraries problem
In the course of cleaning up this b*rked port installed, I found that popt wouldn't install properly. It would report no errors but ports that depended on it would bail out, unable to find shlibs. configure, running under the ports system, returns this: creating libtool checking host system type... i386-unknown-kfreebsd4.9-gnu -- what's that all about? . . . . . checking dynamic linker characteristics... no checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes . . . . Cleaning out the work directory, doing a make deinstall in libtool13 gives me this more reasonable outcome. checking host system type... i386-unknown-freebsd4.9 . . . . checking if libtool supports shared libraries... yes The acid test is to see if make package will work since it seems to check the created files against a list that make install doesn't seem to do. I just did a portinstall rpm (where I was stuck with popt being broken) and it installed just fine. It did however kick back the same warning I have seen previously that libtool13 is deprecated and libtool15 is preferred. There is no warning about the popt port in UPDATING. -- Paul Beard www.paulbeard.org/ paulbeard [at] mac.com
Re: libtool/shared libraries problem
On Thu, Apr 01, 2004 at 12:44:42PM -0800, paul beard wrote: In the course of cleaning up this b*rked port installed, I found that popt wouldn't install properly. It would report no errors but ports that depended on it would bail out, unable to find shlibs. Yes, that's the same problem we've been discussing. Kris pgp0.pgp Description: PGP signature
Re: amd64 -CURRENT: portinstall x11/kde3 fails, missing shared libraries
On Wed, 17 Mar 2004 23:04:24 -0800 Kris Kennaway wrote: On Thu, Mar 18, 2004 at 07:58:35AM +0100, Burkard Meyendriesch wrote: Are there any differences in making ports between i386 STABLE and amd64 CURRENT? What is going wrong? What can I do to solve this? Compare the build logs of the openldap port from i386 and amd64; it's possible the build is turning off shared library support because of a buggy configure script, or something. I have got the same problem with several other libraries on my amd64 box. Here is the relevant difference in config.log between Grimbart (i386 STABLE) and Reineke (amd64 CURRENT) when making libiconv: --- config.log (Reineke) --- LIBICONV='/usr/local/lib/libiconf.a' --- config.log (Grimbart) --- LIBICONV='/usr/local/lib/libiconf.so -Wl, -rpath -Wl, /usr/local/lib' I think this difference is the problem on Reineke. How is LIBICONV generated during the make process? Which part of Reinekes configuration is the reason that it does not make the shared libraries? Burkard -- Burkard Meyendriesch Stevern 2 D-48301 Nottuln ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
amd64 -CURRENT: portinstall x11/kde3 fails, missing shared libraries
Hi folks, on my amd64 CURRENT box I cannot install KDE3; the make install complains about missing shared libraries which should have been made by the ports dependencies: before compiling kdelibs the make installs openldap-client-2.1.27: # ls -l /usr/local/lib/libldap* -rw-r--r-- 1 root wheel 392674 18 Mr 06:09 /usr/local/lib/libldap.a -rw-r--r-- 1 root wheel 714 18 Mr 06:09 /usr/local/lib/libldap.la -rw-r--r-- 1 root wheel 429518 18 Mr 06:09 /usr/local/lib/libldap_r.a -rw-r--r-- 1 root wheel 720 18 Mr 06:09 /usr/local/lib/libldap_r.la # uname -a FreeBSD Reineke.Malepartus.de 5.2-CURRENT FreeBSD 5.2-CURRENT #13: Tue Mar 16 19:33:45 CET 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/REINEKE amd64 On my old i386 STABLE box there is no such problem. Making kde3 succeeds without any problems. It does indeed make shared libs for the dependant libraries: # ls -l /usr/local/lib/libldap* -rw-r--r-- 1 root wheel 242916 11 Mr 11:45 /usr/local/lib/libldap.a lrwxr-xr-x 1 root wheel 12 11 Mr 11:45 /usr/local/lib/libldap.so - libldap.so.2 -rw-r--r-- 1 root wheel 200523 11 Mr 11:45 /usr/local/lib/libldap.so.2 -rw-r--r-- 1 root wheel 266002 11 Mr 11:45 /usr/local/lib/libldap_r.a lrwxr-xr-x 1 root wheel 14 11 Mr 11:45 /usr/local/lib/libldap_r.so - libldap_r.so.2 -rw-r--r-- 1 root wheel 216482 11 Mr 11:45 /usr/local/lib/libldap_r.so.2 # uname -a FreeBSD Grimbart.Malepartus.DE 4.9-STABLE FreeBSD 4.9-STABLE #0: Fri Feb 13 08:31:58 CET 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GRIMBART i386 Are there any differences in making ports between i386 STABLE and amd64 CURRENT? What is going wrong? What can I do to solve this? Burkard -- Burkard Meyendriesch Stevern 2 D-48301 Nottuln ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amd64 -CURRENT: portinstall x11/kde3 fails, missing shared libraries
On Thu, Mar 18, 2004 at 07:58:35AM +0100, Burkard Meyendriesch wrote: Are there any differences in making ports between i386 STABLE and amd64 CURRENT? What is going wrong? What can I do to solve this? Compare the build logs of the openldap port from i386 and amd64; it's possible the build is turning off shared library support because of a buggy configure script, or something. Kris pgp0.pgp Description: PGP signature
Re: Shared libraries
Hello, First a question. Are you using the ports system, or are you experimenting with building from source directly? If the version you want is in ports, you should try that even if you have to apply a patch manually before building, because then all of the libtool mess will be taken care of for you. It's not for nothing that there are no less than 3 versions of libtool in the tree as of now, because not all ports compile with all versions. Therefore simply taking the most recent version of libtool is not guaranteed to work. I do not know the exact cause of the libtool error message you quote, but libtool from ports works for me. On Sat, Aug 16, 2003 at 07:00:13PM -0500, [EMAIL PROTECTED] wrote: Warning: This library needs some functionality provided by -lz. Warning: This library needs some functionality provided by -lcrypt. Warning: This library needs some functionality provided by -lm. But I know about these. So if I had the shared versions of the libraries would that overcome my exim-mysql upgrade problems? From the error output you posted, the answer would be probably (It is missing some functions from libz) If so how or where do I get the shared library versions? You already have them. But the libtool does not find them for some reason. Maybe you could try: env CPPFLAGS=-I/usr/include -I/usr/local/include LDFLAGS=-L/usr/lib -L/usr/local/lib make Hope this helps. -- Regards: Szilveszter ADAM Budapest Hungary ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Shared libraries
I posted the question below earlier on. Following further research it seems that libmysqlclient needs the functions provided by -lz but I don't know how to get that flag into the make file. So I tried reinstalling mysql323-client and noticed the following warning: *** Warning: This library needs some functionality provided by -lz. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lcrypt. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lm. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. So if I had the shared versions of the libraries would that overcome my exim-mysql upgrade problems? If so how or where do I get the shared library versions? TIA Graeme - Forwarded message from [EMAIL PROTECTED] - Date: Fri, 15 Aug 2003 09:42:22 -0500 From: [EMAIL PROTECTED] Subject: Problem upgrading exim-mysql To: [EMAIL PROTECTED] I'm running the exim-mysql package on FreeBSD 4.7 and using the deprecated exiscan patch for virus scanning. I am now trying to upgrade my exim installation from exim-mysql-4.20_1 to the latest exim-mysql-4.21_1, so as to use the new exiscan-acl patch and make use of the new exim 4.21 features. I am using the command portupgrade -v exim-mysql to perform the upgrade but get the following error: == /usr/local/lib/mysql/libmysqlclient.so: undefined reference to `uncompress' /usr/local/lib/mysql/libmysqlclient.so: undefined reference to `compress' *** Error code 1 Stop in /usr/ports/mail/exim-mysql/work/exim-4.21/build-FreeBSD-i386. *** Error code 1 Stop in /usr/ports/mail/exim-mysql/work/exim-4.21. *** Error code 1 Stop in /usr/ports/mail/exim-mysql. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade15850.0 mak e ** Fix the problem and try again. == Has anyone any ideas as to how I might Fix the problem? TIA Graeme - End forwarded message - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Shared libraries
Well, I'm still trying to sort this problem out (for continuity my first two posts can be found below) but I'm getting near the end of my tether with this one and not sure where to go next. I'm very tempted just to give up on FreeBSD and try Debian. I have tried reinstalling libtool from the ports as I believe libtool has something to do with shared libraries. It installs OK but I get this warning during the install process == Warning: the command libtool uses to detect shared libraries, /usr/bin/file, produces output that libtool cannot recognize. The result is that libtool may fail to recognize shared libraries as such. This will affect the creation of libtool libraries that depend on shared libraries, but programs linked with such libtool libraries will work regardless of this problem. Nevertheless, you may want to report the problem to your system manager and/or to [EMAIL PROTECTED] === Now this may or may not be the root of my problem, but if it is what is the solution? I'm completely at a loss! Can anyone point me in the right direction please! Thanks Graeme - Forwarded message from [EMAIL PROTECTED] - Date: Fri, 15 Aug 2003 20:18:11 -0500 I posted the question below earlier on. Following further research it seems that libmysqlclient needs the functions provided by -lz but I don't know how to get that flag into the make file. So I tried reinstalling mysql323-client and noticed the following warning: Warning: This library needs some functionality provided by -lz. I have the capability to make that library automatically link in when you link to this library. But I can only do this if you have a shared version of the library, which you do not appear to have. Warning: This library needs some functionality provided by -lcrypt. I have the capability to make that library automatically link in when you link to this library. But I can only do this if you have a shared version of the library, which you do not appear to have. Warning: This library needs some functionality provided by -lm. I have the capability to make that library automatically link in when you link to this library. But I can only do this if you have a shared version of the library, which you do not appear to have. The inter-library dependencies that have been dropped here will be automatically added whenever a program is linked with this library or is declared to -dlopen it. So if I had the shared versions of the libraries would that overcome my exim-mysql upgrade problems? If so how or where do I get the shared library versions? TIA Graeme - Forwarded message from [EMAIL PROTECTED] - Date: Fri, 15 Aug 2003 09:42:22 -0500 I'm running the exim-mysql package on FreeBSD 4.7 and using the deprecated exiscan patch for virus scanning. I am now trying to upgrade my exim installation from exim-mysql-4.20_1 to the latest exim-mysql-4.21_1, so as to use the new exiscan-acl patch and make use of the new exim 4.21 features. I am using the command portupgrade -v exim-mysql to perform the upgrade but get the following error: == /usr/local/lib/mysql/libmysqlclient.so: undefined reference to `uncompress' /usr/local/lib/mysql/libmysqlclient.so: undefined reference to `compress' Error code 1 Stop in /usr/ports/mail/exim-mysql/work/exim-4.21/build-FreeBSD-i386. Error code 1 Stop in /usr/ports/mail/exim-mysql/work/exim-4.21. Error code 1 Stop in /usr/ports/mail/exim-mysql. Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade15850.0 mak e Fix the problem and try again. == Has anyone any ideas as to how I might Fix the problem? TIA Graeme - End forwarded message - - End forwarded message - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
On Tue, Jun 17, 2003 at 06:38:29AM -0700, Joe Kelsey wrote: Basically, what I want to do is remove several entries from the *front* of the dynamic section. Actually, I would settle for just removing all of a certain tag (such as DT_NEEDED) from the dynamic section. I'm very interested, having a working Flash 6 would be great! Isn't there a way to change these into bogus dependencies, or dependencies on a FreeBSD shared object or something? --Stijn -- In the force if Yoda's so strong, construct a sentence with words in the proper order then why can't he? pgp0.pgp Description: PGP signature
Re: Tools to modify shared libraries
Stijn Hoop wrote: On Tue, Jun 17, 2003 at 06:38:29AM -0700, Joe Kelsey wrote: Basically, what I want to do is remove several entries from the *front* of the dynamic section. Actually, I would settle for just removing all of a certain tag (such as DT_NEEDED) from the dynamic section. I'm very interested, having a working Flash 6 would be great! Isn't there a way to change these into bogus dependencies, or dependencies on a FreeBSD shared object or something? No. I removed the dependencies by manually editing the .so with emacs... Now, here is a list of the undefined symbols beginning with __: 598: 79 FUNCGLOBAL DEFAULT UND [EMAIL PROTECTED] (4) 939: 231 FUNCGLOBAL DEFAULT UND [EMAIL PROTECTED] (2) 1129: 109 FUNCGLOBAL DEFAULT UND [EMAIL PROTECTED] (4) 1656: 172 FUNCWEAK DEFAULT UND __deregister_frame_info 1703: 815 FUNCGLOBAL DEFAULT UND [EMAIL PROTECTED] (2) 1952: 815 FUNCGLOBAL DEFAULT UND [EMAIL PROTECTED] (2) 2133: 4 OBJECT GLOBAL DEFAULT UND [EMAIL PROTECTED] (2) 2763: 157 FUNCWEAK DEFAULT UND [EMAIL PROTECTED] (9) 3161: 4 OBJECT GLOBAL DEFAULT UND [EMAIL PROTECTED] (2) 3319: 1642 FUNCGLOBAL DEFAULT UND [EMAIL PROTECTED] (2) 3376: 26 FUNCGLOBAL DEFAULT UND __terminate 3624: 129 FUNCWEAK DEFAULT UND __register_frame_info 3716: 0 NOTYPE WEAK DEFAULT UND __gmon_start__ The old flash library had these symbols: 34: 0 NOTYPE GLOBAL DEFAULT UND __builtin_vec_new 36: 0 NOTYPE GLOBAL DEFAULT UND __builtin_vec_delete 1163: 0 NOTYPE GLOBAL DEFAULT UND __errno_location flashpluginwrapper provides the two __builtin references. I do not think we need to provide the WEAK symbols. We do need to provide the others, specifically __write, __ctype_toupper, __ctype_b, __assert_failure, __xstate, __fxstate, and __strtoul_internal. Anyone want to start modifying flashpluginwrapper? /Joe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
Apparently, On Mon, Jun 16, 2003 at 03:39:19PM -0700, Joe Kelsey said words to the effect of; Has anyone ever come across general-purpose tools for modifying shared libraries? What I want to do is to edit the list of needed shared libraries to correct the common mistakes that developers make in creating shared objects with large lists of shared libraries. Specifically, I want to modify linux-flashplugin6/libflashplayer.so to remove all of the idiotic references to shared libraries that the Flash 6 developers added. Since this is a plugin for Mozilla, it does not need to specify any extra shared libraries especially since Mozilla has already loaded all of them! I want to do this to make Flash 6 work with flashpluginwrapper. If I can remove the list of needed shared libraries from the DYNAMIC section of the shared library, everyone will be that much closer to a real flash 6 plugin for BSD. I've needed to do similar things to remove the interp section from static binaries with full dynamic symbol tables. I just wrote a C program that mmapped the elf file, parsed the headers and changed the p_type of the PT_INTERP program header entries to PT_NULL. You may be able to do something similar by changing the d_tag of the DT_NEEDED entries to some value larger than DT_COUNT so they will be ignored by the dynamic linker. Jake ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
Brandon S. Allbery KF8NH wrote: On Mon, 2003-06-16 at 18:39, Joe Kelsey wrote: Has anyone ever come across general-purpose tools for modifying shared libraries? What I want to do is to edit the list of needed shared libraries to correct the common mistakes that developers make in creating shared objects with large lists of shared libraries. GNU objcopy --- but it's a bit *too* general; you'd need to extract the .dynamic section, edit it using some binary editing tool, and re-add it. I have tried and failed... I even looked at the code. objcopy is horrible as far as it goes. Maybe if I could learn more about bfd in general, there might be something I could do with objcopy, but it does not look promising. I doubt there are any tools of the kind you're looking for because the details are too different between different systypes; even if someone had developed one, it's just as likely to be for Linux or Solaris as for *BSD, and as a result wouldn't be particularly useful. All 32-bit Elf libraries look the same as far as the DT_NEEDED entries in the DYNAMIC section. In fact, *all* ELF libraries look the same relative to the size of the string table offset used for entries. The DYNAMIC section is the simplest of all sections, generally consisting of a tag and a value, both in the native word size (e.g., 32 or 64). I am surprised that no one has done this yet. I tried elfsh, but the version in ports is too old. I got the most recent version from the website, but it has a lot of linuxisms in it. Basically, what I want to do is remove several entries from the *front* of the dynamic section. Actually, I would settle for just removing all of a certain tag (such as DT_NEEDED) from the dynamic section. /Joe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
On Tue, Jun 17, 2003 at 06:38:29AM -0700, Joe Kelsey wrote: Basically, what I want to do is remove several entries from the *front* of the dynamic section. Actually, I would settle for just removing all of a certain tag (such as DT_NEEDED) from the dynamic section. It's more constructive to fix the linker than it is to patch the ELF files created by it. The linker knows which libraries are really needed and should be able to create the minimal list of (true) dependencies. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
Marcel Moolenaar wrote: On Tue, Jun 17, 2003 at 06:38:29AM -0700, Joe Kelsey wrote: Basically, what I want to do is remove several entries from the *front* of the dynamic section. Actually, I would settle for just removing all of a certain tag (such as DT_NEEDED) from the dynamic section. It's more constructive to fix the linker than it is to patch the ELF files created by it. The linker knows which libraries are really needed and should be able to create the minimal list of (true) dependencies. This cannot be accomplished by fixing the linker. The issue is one of attempting to use a *linux* shared library in a native application. Have you ever lookad at the flashpluginwarpper port? It provides a library to perload which intercepts the linux syscalls and translates them to bsd syscalls to allow linux shared libraries (specifically, the linux flash library) in native binaries. This works fine for the old flash plugin since that shared library did not include any DT_NEEDED entires in its .dynamic section. However, the new Flash 6 linux shared library has a number of explicit references to linux-only shared libraries as DT_NEEDED references in its .dynamic section. This prevents us from using the flashpluginwrapper trick to allow use of Flash 6 in native Mozilla. Do you understand now? /Joe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
On Tue, Jun 17, 2003 at 08:49:23AM -0700, Joe Kelsey wrote: Marcel Moolenaar wrote: On Tue, Jun 17, 2003 at 06:38:29AM -0700, Joe Kelsey wrote: Basically, what I want to do is remove several entries from the *front* of the dynamic section. Actually, I would settle for just removing all of a certain tag (such as DT_NEEDED) from the dynamic section. It's more constructive to fix the linker than it is to patch the ELF files created by it. The linker knows which libraries are really needed and should be able to create the minimal list of (true) dependencies. This cannot be accomplished by fixing the linker. The issue is one of attempting to use a *linux* shared library in a native application. Linux uses the same linker (GNU ld). Fixing the linker will have the same effect on Linux as it will have on FreeBSD and hence will prevent unnecessary dependencies in Linux libraries to Linux libraries and thus remove the need to patch ELF files in the long run. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
Marcel Moolenaar wrote: On Tue, Jun 17, 2003 at 08:49:23AM -0700, Joe Kelsey wrote: Marcel Moolenaar wrote: On Tue, Jun 17, 2003 at 06:38:29AM -0700, Joe Kelsey wrote: Basically, what I want to do is remove several entries from the *front* of the dynamic section. Actually, I would settle for just removing all of a certain tag (such as DT_NEEDED) from the dynamic section. It's more constructive to fix the linker than it is to patch the ELF files created by it. The linker knows which libraries are really needed and should be able to create the minimal list of (true) dependencies. This cannot be accomplished by fixing the linker. The issue is one of attempting to use a *linux* shared library in a native application. Linux uses the same linker (GNU ld). Fixing the linker will have the same effect on Linux as it will have on FreeBSD and hence will prevent unnecessary dependencies in Linux libraries to Linux libraries and thus remove the need to patch ELF files in the long run. The problem cannot be resolved by fixing ld. The problem arises from people who specify unnecessary libraries on their ld command lines. ld cannot tell the difference between a required library and an unnecessary library at link time. Only the runtime loader can do this, and the FreeBSD runtime loader has numerous problems in this area. Sometimes a shared library has to include a required library reference since the shared library author knows in advance that the programs using the library do not have the same requirements. Most often, clueless programmers reference every single library ever known to them on their linker command lines in the off-chance that it *might* make a difference at load time. However, this leads to shared libraries containing references to explicitlyly versioned libraries, thus leading to the proliferation of unnecessarily versioned shared libraries, etc., etc. I can think of many reasons for post-linker tools to modify shared libraries. Most of them involve fixing the egregious mistakes perpetrated by users who have not thought out what requirements a shared library outgt to carry with it. Others involve patching and other kinds of code modification. /Joe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
On Tue, Jun 17, 2003 at 09:13:04AM -0700, Joe Kelsey wrote: It's more constructive to fix the linker than it is to patch the ELF files created by it. The linker knows which libraries are really needed and should be able to create the minimal list of (true) dependencies. This cannot be accomplished by fixing the linker. The issue is one of attempting to use a *linux* shared library in a native application. Linux uses the same linker (GNU ld). Fixing the linker will have the same effect on Linux as it will have on FreeBSD and hence will prevent unnecessary dependencies in Linux libraries to Linux libraries and thus remove the need to patch ELF files in the long run. The problem cannot be resolved by fixing ld. The problem arises from people who specify unnecessary libraries on their ld command lines. ld cannot tell the difference between a required library and an unnecessary library at link time. Yes it can. Symbol resolution is a fundamental part in linking. Hence, the linker has all the information it needs to filter the gratuitously long list of libraries programmers tend to give it and keep the libraries that actually contributed to the link. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
Marcel Moolenaar wrote: Yes it can. Symbol resolution is a fundamental part in linking. Hence, the linker has all the information it needs to filter the gratuitously long list of libraries programmers tend to give it and keep the libraries that actually contributed to the link. I know of no way to do this in the case of shared libraries. When linking shared libraries, the linker *cannot* resolve any references to other shared libraries other than list them in the .dynamic section with some sort of tag such as DT_NEEDED. Please explain to me how the linker can prune the shared library list at link time. Sorry that this has veered off into a dead-end. I promise to cut the mailing list from any further discussions on this dead-end thread. /Joe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
On Tue, Jun 17, 2003 at 09:31:54AM -0700, Joe Kelsey wrote: Marcel Moolenaar wrote: Yes it can. Symbol resolution is a fundamental part in linking. Hence, the linker has all the information it needs to filter the gratuitously long list of libraries programmers tend to give it and keep the libraries that actually contributed to the link. I know of no way to do this in the case of shared libraries. When linking shared libraries, the linker *cannot* resolve any references to other shared libraries other than list them in the .dynamic section with some sort of tag such as DT_NEEDED. Please explain to me how the linker can prune the shared library list at link time. If a symbol is unresolved, it must be present in one of the libraries on the link line. If the symbol is in an archive library, you pull in the code. Otherwise, if it's in a shared library, you record the dependency on that library. In the end you have no unresolved symbols, all code from archives has been linked in and you have a complete list of dependencies that is a subset of the libraries given on the command line. For partial linking (incremental linking) the list of unresolved symbols does not have to be empty. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
On Tue, 17 Jun 2003 09:01:41 -0700 Marcel Moolenaar [EMAIL PROTECTED] wrote: On Tue, Jun 17, 2003 at 08:49:23AM -0700, Joe Kelsey wrote: Linux uses the same linker (GNU ld). Fixing the linker will have the same effect on Linux as it will have on FreeBSD and hence will prevent unnecessary dependencies in Linux libraries to Linux libraries and thus remove the need to patch ELF files in the long run. LD putting a library in DT_NEEDED regardless of whether or not library exports any required symbols as long as it appears on command line is a feature, not a bug AFAIK. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
In the last episode (Jun 17), Marcel Moolenaar said: On Tue, Jun 17, 2003 at 01:02:36PM -0400, Alexander Kabaev wrote: On Tue, 17 Jun 2003 09:01:41 -0700 Marcel Moolenaar [EMAIL PROTECTED] wrote: On Tue, Jun 17, 2003 at 08:49:23AM -0700, Joe Kelsey wrote: Linux uses the same linker (GNU ld). Fixing the linker will have the same effect on Linux as it will have on FreeBSD and hence will prevent unnecessary dependencies in Linux libraries to Linux libraries and thus remove the need to patch ELF files in the long run. LD putting a library in DT_NEEDED regardless of whether or not library exports any required symbols as long as it appears on command line is a feature, not a bug AFAIK. It's a bug because DT_NEEDED serves the purpose of recording library dependencies. Any library that does not contribute to symbol resolution is by definition not a dependency. Hence, its presence in DT_NEEDED only makes the dependency information wrong. Dependency information that's wrong is untrustworthy and unreliable and thus unusable. Hence, a bug. Immediate consequences of broken dependency information is the increased startup time of shared binaries, the restriction in use of libraries in cases where they can be used and the obstruction in replacing libraries with different implementations by possibly causing artificial conflicts due to unnecessary loading of libraries. Only explicit user directives should allow adding libraries to DT_NEEDED regardless of whether there's actually a dependency. Dependencies can change after a program is linked, though. How about the contrived case of a program needing the openpty function, so -lutil is linked in. Then 6 months later openpty is moved to libc, making the dependency on libutil unneeded. The end result is the same as if a new program is unnecessarily linked with -lutil, but cannot be fixed with ld because at the time it was linked, the first program actually did need libutil. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
On Tue, Jun 17, 2003 at 01:02:36PM -0400, Alexander Kabaev wrote: On Tue, 17 Jun 2003 09:01:41 -0700 Marcel Moolenaar [EMAIL PROTECTED] wrote: On Tue, Jun 17, 2003 at 08:49:23AM -0700, Joe Kelsey wrote: Linux uses the same linker (GNU ld). Fixing the linker will have the same effect on Linux as it will have on FreeBSD and hence will prevent unnecessary dependencies in Linux libraries to Linux libraries and thus remove the need to patch ELF files in the long run. LD putting a library in DT_NEEDED regardless of whether or not library exports any required symbols as long as it appears on command line is a feature, not a bug AFAIK. It's a bug because DT_NEEDED serves the purpose of recording library dependencies. Any library that does not contribute to symbol resolution is by definition not a dependency. Hence, its presence in DT_NEEDED only makes the dependency information wrong. Dependency information that's wrong is untrustworthy and unreliable and thus unusable. Hence, a bug. Immediate consequences of broken dependency information is the increased startup time of shared binaries, the restriction in use of libraries in cases where they can be used and the obstruction in replacing libraries with different implementations by possibly causing artificial conflicts due to unnecessary loading of libraries. Only explicit user directives should allow adding libraries to DT_NEEDED regardless of whether there's actually a dependency. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Tools to modify shared libraries
Has anyone ever come across general-purpose tools for modifying shared libraries? What I want to do is to edit the list of needed shared libraries to correct the common mistakes that developers make in creating shared objects with large lists of shared libraries. Specifically, I want to modify linux-flashplugin6/libflashplayer.so to remove all of the idiotic references to shared libraries that the Flash 6 developers added. Since this is a plugin for Mozilla, it does not need to specify any extra shared libraries especially since Mozilla has already loaded all of them! I want to do this to make Flash 6 work with flashpluginwrapper. If I can remove the list of needed shared libraries from the DYNAMIC section of the shared library, everyone will be that much closer to a real flash 6 plugin for BSD. /Joe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
On Mon, 2003-06-16 at 18:39, Joe Kelsey wrote: Has anyone ever come across general-purpose tools for modifying shared libraries? What I want to do is to edit the list of needed shared libraries to correct the common mistakes that developers make in creating shared objects with large lists of shared libraries. GNU objcopy --- but it's a bit *too* general; you'd need to extract the .dynamic section, edit it using some binary editing tool, and re-add it. I doubt there are any tools of the kind you're looking for because the details are too different between different systypes; even if someone had developed one, it's just as likely to be for Linux or Solaris as for *BSD, and as a result wouldn't be particularly useful. -- brandon s allbery [openafs/solaris/japh/freebsd] [EMAIL PROTECTED] system administrator [linux/heimdal/too many hats] [EMAIL PROTECTED] electrical and computer engineering KF8NH carnegie mellon university [better check the oblivious first -ke6sls] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
combining shared libraries into 1 library?
Is it possible to combine 2 shared libraries into a single library? I've read the ld(1) man page, but it isn't clear whether this is possible. I would like to do ld -Bsharable -o libX.so libY.so libZ.so where libY.so are libZ.so are combined into libX.so. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
