Re: Replacing ar with libtool
Hi, On 8/10/24 20:08, Navin P wrote: When i run make -j1 i find all the object files libx.a but when i do make -j8 i find some missing object files inside libx.a. Typically you'd generate all objects first, then archive them in a single invocation. This is I/O bound anyway, so you're not losing much from being single-threaded, and rerunning Make after a partial/failed build knows exactly which objects are missing. Consider: libx.a: a.o b.o $(AR) cru $@ $^ .c.o: $(CC) -o $@ -c $< If you build a.o and add it to libx.a, then the next invocation of Make will compare the timestamp of libx.a against the timestamp of b.c, because b.o is an intermediate object, so the assumption is that it does not exist because it was successfully built and consumed by the only rule that references it. This is safe only if the library is created last, i.e. will always have a timestamp that is later than any source files that go into it, so you cannot create an intermediate version of the library. Libtool supports "convenience libraries", which are unpacked and repacked automatically to merge all objects to a single large library. That takes a bit of extra time in a build and cannot be parallelized either, but in large projects it makes the Makefile.am a little more readable. Simon OpenPGP_signature.asc Description: OpenPGP digital signature
Re: What does -no-fast-install libtool option do?
Hi, On 26.03.2018 18:57, Basin Ilya wrote: > The expected drawback is a slower `make install`, but I'm fine with it. That doesn't work for most use cases, where the build is running as an user, while "make install" runs as root. "make install" should not write anything to the build tree, because it would create files owned by root then, which the user would not be able to delete. This is why it's impossible to relink at this stage. Simon signature.asc Description: OpenPGP digital signature ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
Hi, On 10.02.2016 17:49, Vadim Zeitlin wrote: > *** Warning: Trying to link with static lib archive > /opt/msw/i686-w64-mingw32/lib/libboost_filesystem.a. > *** 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 > *** because the file extensions .a of this argument makes me believe > *** that it is just a static archive that I should not use here. Linking a static library into a shared library will only ever work on Windows, and (with lots of warnings) Linux on 32-bit x86, because these two platforms are the only ones supporting run-time relocation of code that wasn't compiled to be position independent. On Windows, that is the default behaviour -- all PE binaries are completely relocatable, mostly because Windows 3.11 required that. On Linux for i386, the dynamic linker supports relocations outside the GOT and PIC, which creates unshareable pages and generally sucks, but was necessary to port some software back then. So support for linking shared into static libraries is essentially "win32 only", but creating a special mode for that would make no sense, because then the source would no longer be portable and we wouldn't need libtool. The extra hoops for creating Windows DLLs are due to additional constraints on the source code, but this would be relaxing a constraint that exists on all platforms but one. Libtool should in principle find the import library for the DLL and link against that. Boost is a little bit special because they encode the version number and several compiler options in the DLL name. Does it link correctly if you use the fully decorated name (because that is also what you'd use on Linux)? Simon signature.asc Description: OpenPGP digital signature ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling C++
Hi, On 06.07.2015 20:17, martin wrote: > Random files are generated wth .loT file type. Files ending in T are temporary files that are generated because some compilers do not delete the output file on failure. These are renamed to the same name without the T at the end of the build step they belong to. If these remain somewhere, then something went wrong, for example an aborted build didn't clean them up. Files with the suffix .lo are generated by libtool, these are normal object files (.o), but compiled with the options necessary for shared libraries. The .loT files you see are thus remnants of a compiler invocation from libtool, and got left when a build was aborted or failed because the harddisk ran full. They can be safely deleted. Simon signature.asc Description: OpenPGP digital signature ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Avoid exporting of internal symbols
Hi, On 04.03.2013 07:23, Satz Klauer wrote: > libtool --mode=compile g++ -Wall -fPIC -shared -Wno-unused [...] > As far as I understood it, the statement "-export-symbols-regex > mylib_" should ensure only functions starting with "mylib_" should be > exported by the resulting library. Indeed, however that functionality is currently broken for C++. There is a patch that supposedly fixes that[1]. Simon [1] https://lists.gnu.org/archive/html/libtool/2013-02/msg0.html ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: link-time optimization
Hi, On Sun, Mar 28, 2010 at 05:33:44PM +0200, Ralf Wildenhues wrote: > * doc/libtool.texi (FAQ, Stripped link flags): New nodes. > (Wrapper executables): Replace bug address with macro. > (Compile mode, Link mode): Document `-Wc,' and `-Xcompiler ' > semantics better. Hmm, -Wc is difficult to use because the compiler does not handle it -- hence I cannot pass it to the configure script. Manually patching config.status to use "-Wc,-flto" works fine though (this is a project where all building goes through libtool, so it's possible). Thanks, Simon signature.asc Description: Digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
link-time optimization
Hi, I'm trying to use link time optimization with gcc 4.5, which somewhat works :), but requires the compiler flags to be passed to the linking step as well. libtool however removes them from the command line. Is there any harm in passing them to the linking step? Simon signature.asc Description: Digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
relinking and cross-compiling
Hi, I'm using libtool in a project that builds a few shared libraries, a main program and plugins to the program, all in the same source package. I've made Debian style packages from my source tree, which requires installation into DESTDIR to work. In the native case, this works: /bin/sh ../libtool --mode=install /usr/bin/install -c interfaces.la '/srv/repo/build/sid/sge_0.0.20100322-1_amd64/debian/tmp/usr/lib/sge/backend' libtool: install: warning: relinking `interfaces.la' libtool: install: (cd /srv/repo/build/sid/sge_0.0.20100322-1_amd64/interfaces; /bin/sh /srv/repo/build/sid/sge_0.0.20100322-1_amd64/libtool --tag CXX --mode=relink x86_64-linux-gnu-g++ -g -O2 -fvisibility=hidden -module -avoid-version -no-undefined -o interfaces.la -rpath /usr/lib/sge/backend linux_network_service.lo plugin.lo network_service.lo ../libsge-agent.la -llazybox -inst-prefix-dir /srv/repo/build/sid/sge_0.0.20100322-1_amd64/debian/tmp) libtool: relink: x86_64-linux-gnu-g++ -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtbeginS.o .libs/linux_network_service.o .libs/plugin.o .libs/network_service.o -L/srv/repo/build/sid/sge_0.0.20100322-1_amd64/debian/tmp/usr/lib -L/usr/lib -lsge-agent -llazybox -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crtn.o -Wl,-soname -Wl,interfaces.so -o .libs/interfaces.so libtool: install: /usr/bin/install -c .libs/interfaces.soT /srv/repo/build/sid/sge_0.0.20100322-1_amd64/debian/tmp/usr/lib/sge/backend/interfaces.so However, cross compiled packages fail here: /bin/sh ../libtool --mode=install /usr/bin/install -c interfaces.la '/srv/repo/build/sid/sge_0.0.20100322-1_armel/debian/tmp/usr/lib/sge/backend' libtool: install: warning: relinking `interfaces.la' libtool: install: (cd /srv/repo/build/sid/sge_0.0.20100322-1_armel/interfaces; /bin/sh /srv/repo/build/sid/sge_0.0.20100322-1_armel/libtool --tag CXX --mode=relink arm-linux-gnueabi-g++ -g -O2 -fvisibility=hidden -module -avoid-version -no-undefined -o interfaces.la -rpath /usr/lib/sge/backend linux_network_service.lo plugin.lo network_service.lo ../libsge-agent.la -llazybox -inst-prefix-dir /srv/repo/build/sid/sge_0.0.20100322-1_armel/debian/tmp) libtool: relink: arm-linux-gnueabi-g++ -shared -nostdlib /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib/crti.o /usr/lib/gcc/arm-linux-gnueabi/4.3.2/crtbeginS.o .libs/linux_network_service.o .libs/plugin.o .libs/network_service.o -Wl,-rpath -Wl,/usr/arm-linux-gnueabi/lib -L/srv/repo/build/sid/sge_0.0.20100322-1_armel/debian/tmp/usr/lib -L/usr/lib -lsge-agent -L/srv/repo/build/sid/sge_0.0.20100322-1_armel/debian/tmp/usr/arm-linux-gnueabi/lib -L/usr/arm-linux-gnueabi/lib -llazybox -L/usr/lib/gcc/arm-linux-gnueabi/4.3.2 -L/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/arm-linux-gnueabi/4.3.2/crtendS.o /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib/crtn.o -Wl,-soname -Wl,interfaces.so -o .libs/interfaces.so /usr/lib/liblazybox.so: file not recognized: File format not recognized collect2: ld returned 1 exit status The problem here appears to be the "-L/usr/lib", which I suspect comes from $libdir. I'm not sure the "installed" $libdir should ever be searched for libraries, unless it also happens to be in the compiler's default path (which it is in the native case). If the "-L/usr/lib" is omitted, relinking works (the proper liblazybox.so is then found in /usr/arm-linux-gnueabi/lib). I can work around the problem by splitting the package, compiling the libraries separately and installing them before building the plugins (in this case, no relinking step is necessary). Simon signature.asc Description: Digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Circular dependencies between shared libraries, an (icky) use case
Hi, I have a project with two libraries exposing different levels of detail to the user, basically one provides (C++) base classes with some functionality, and the other one provides classes derived from those with the actual implementation. Since the latter is going to change often, I'd rather not expose the derived interface to anyone who doesn't need it, to save me from rebuilding and relinking all applications and bumping SONAME all of the time. Now, the two libraries, let's call them libbase and libderived, have mutual references: libbase needs to call into libderived to construct the actual object, and libderived needs to call into libbase for functions that are implemented in the base classes but called from the derived ones. The desired result is that applications that are content with the base interface can link against libbase and ignore libderived, and applications that require full access to the derived interface link against both libraries. When the derived interface changes, I can then bump the SONAME of libderived, and rebuild libbase and all apps that directly link against libderived, and get back to a consistent set. Is something like this possible using libtool, and if so, can it be done portably? Simon signature.asc Description: Digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Opening libraries by soname
Hi, Paolo Bonzini schrieb: In debian, libncurses.so is not installed unless libncurses-dev is also installed. Therefore, programs should open libncurses.so.5 directly. No. Ideally the installation script for your program would create a symlink from a private directory for your program to the libncurses that your program should open, which would probably point to the SONAME symlink. Simon ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Making shared libraries (DLLs) on Windows: -no-undefined
Hi,
John Brown wrote:
> I gather that on Linux, you *can* create a shared library with undefined
> symbols.
Indeed.
> 1) Why would anyone do that intentionally?
To link against another library, or to import a symbol defined by the
main program or a library loaded by the main program before. The latter
is heavily discouraged of course, as it is not portable; still a lot of
people do this in their plugin interfaces.
> 2) Assuming that it was a mistake, could it happen silently?
Yes, unless -no-undefined is in place.
> 3) What are the consequences?
Depending on whether the dynamic linker is in lazy or proactive mode,
the program is terminated when the undefined symbol is first referenced
or when the library is loaded.
Library imports happen quite different on PE platforms, rather than
implicitly through the dynamic linker tables in the objects, there has
to be glue code that explicitly looks up the symbol. Presence of
undefined symbols in a PE object simply means that you forgot to mark a
place where the symbol is referenced as requiring glue code
("__declspec(dllimport)"). Also, IIRC this is only possible for C
functions with stdcall ABI (I believe there to be some kludge in Windows
that adjusts the stack for you, but I'm not sure whether that applies to
WNDPROC functions only).
If you set "-no-undefined", you are basically saying that your library
does not reference any symbols from objects not listed on the linker
command line, on either platform. As ELF does not care, but PE does,
libtool asks you to state that your code is safe for linking into a PE
shared object.
Hope this helps,
Simon
___
http://lists.gnu.org/mailman/listinfo/libtool
linking a module for a testcase
Hello, I'm trying to write testcases for a plugin loader (basically a C++ wrapper around ltdl that takes care of registering the new creators in the factories), and for this, I need to link a plugin that is then supposed to be loaded from the testcases. For some reason, libtool builds said plugin static-only, probably because automake passes a hint about that. Obviously, I'd need shared-only with a fallback on static-only for systems that need to dlpreopen. I could even live with both shared and static modules being built :-) . Is there any way to tell libtool "Yes, I know this thing is not going to be installed, but I'd like to have a shared library anyway."? Simon ___ http://lists.gnu.org/mailman/listinfo/libtool
RFC: Support for unstable ABIs
Hi, a lot of projects that are just starting out still make quite a lot of changes to their library ABI, so it does not make full sense to build a shared library right away, but sometimes it is still necessary to have PIC code around, for example when building a plugin to be dlopen()ed by some program. If said library and the plugin code also live in separate packages, you have a bit of a problem with current libtool. The idea at this point would be to add another switch "-unstable-abi", which would make libtool generate an archive instead of a shared library (as it would for a convenience library), but also install both variants (perhaps as libfoo.a and libfoo_pic.a). Shared object links against that library would then simply include the ..._pic.a file on the linker command line. Comments? Simon ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: PIE support
Hi, Mike Frysinger wrote: I don't know, but PIE and PIC don't compile to same thing AFAICT. I don't know the significance of that though. IIRC -pie is only a linker flag that a) affects selection of the linker script b) disallows certain relocation types c) notes the position-independence in the resulting binary Some platforms have a provision in the specs that allows -pie to be given to the gcc frontend, resulting in -fPIC for compilations and -pie for linking. PIE and PIC arent the same thing Only in the linker stage. PIC objects export dynamic symbols and reference their own exported symbols dynamically as well, allowing LD_PRELOAD to override symbols inside a library. PIE objects don't do that. Simon signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
library with static-only parts
Hi, a library I'm writing has the possibilty of being extended with plugins that can be loaded with ltdl. In order to avoid having to export lt_dlpreloaded_symbols from the main program to the library (thus making prelinking impossible and being generally ugly and unportable). I'd like to have a library where parts are available as a static library only, that should be automatically linked when linking against the shared library with libtool. Is there a way to do that? Simon signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Hi, Keith Packard wrote: > I want the SONAME to be libXaw.so.6, but the filename to be libXaw6.la, > libXaw6.so.6.0.1, libXaw6.so.6 and libXaw6.so There is no need to name the real file libXaw6.so.6.0.1, as the 6 is mentioned twice this way (libXaw.so.6.0.1 suffices). The unversioned symlink and the .la file are the only things that conflict between versions; I'd think that there is some sort of a "current" ABI which would get its symlink/.la installed. Now I'm wondering whether it would make sense to add a switch to libtool that makes it not install those two things, such as "-old-abi". Simon ___ http://lists.gnu.org/mailman/listinfo/libtool
modules dlopened from a library
Hi, I have a shared library that internally uses plugins that are dlopened (or dlpreopened). For this to work, I basically have the following options: - Have the application load the list of preloaded symbols. This means that the application programmer needs to be aware that my library uses ltdl, and that the library will fail in Unobvious And Interesting(tm) ways if she forgets to do so. - Have the library load the list of preloaded symbols. This means that any application will have to define lt_preloaded_symbols, even if it is just a configure test application; also it introduces a dependency from a library to the program, which is permitted on GNU systems at the cost of a COW page being touched, but not very portable. - Have libtool add a specific .o file to every app. I'm not sure whether this is possible in a sane way, hence I'm asking, but to me it appears that if libtool could be kicked into adding a .o file to dependency_libs when building the library, said file would be linked to every application when libtool is used to link the app. This still means that if the application is linked without libtool, it will fail in U&I(tm) ways, but at least I can build a configure script that tests for the library's presence, and be somewhat portable. Is there another, perhaps more sane, way to achieve this? Simon signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: whole_archive/-r
Hi, 1) I have a C++ library that makes use of global constructors. This should also work when using static libraries, as long as the global constructors are contained within the same archive member as the object they construct, and everyone who uses the result from a static initialization also has a reference to that object. I suppose you are using a globally constructed object to perform some other initialization that is not related to the object. It should be possible to give the global object an "operator bool(void) const", test that condition at appropriate places (i.e. once per translation unit where you rely on the initialization) and define the cast-to-bool operator in the same translation unit as the object's constructor. That way, you will always pull in the constructor when it is required. Simon signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Including static libraries in shared libraries with libtool.
Hi, > My intentions here are: > Build the sources for libauthuserdb.la. Take their object code, and grab > whatever modules from libauth.la that are references by stuff in > libauthuserdb.la, and place all of that into a shared library. Not possible without reimplementing parts of the linker. Parts of static libraries cannot be linked into shared libraries, as shared libs need to be compiled as position independent code (ld.so on ix86 linux can work around that by mapping the offending library into a private mapping and relocating it, but that is a huge waste of memory and not portable). > Unfortunately, the actual results are different. There are two problem: > 1. Libtool takes _all_ modules from libauth.la, and puts them into > libauthuserdb.la. I only want the modules that libauthuserdb.la actually > needs. A "convenience library", as a libtool library that is not installed is called, is linked into each object that uses it. If the object is a library, it is copied completely, otherwise, it is linked statically. This feature is intended for huge libraries that are built from multiple subdirectories, where each subdir builds a convenience lib and everything is linked in the end. > 2. For some reason, only the static version of libauthuserdb.la is > generated. I don't know why, but libauthuserdb.so is not created, only > libauthuserdb.a is created. I am _not_ using the --disable-shared flag > with the configure script. There is no way to build a shared library, as parts of it are only available as non-PIC code. > However, this is not practical. I'm building several shared libraries that > use different bits and pieces of the common code, and manually tracking > which common source module is used by which shared library is cumbersome. I > need to coerce libtool in doing this job for me. If there may be additional shared libs that may be built outside of the source tree, you may be better off making a ...-util library that is installed and linked by all of your other libraries. This is transparent to the user, but permits everyone to write their own libraries linking against the -util library. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 signature.asc Description: Digital signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Using libtool together with the ${ORIGIN} soname variable
Hi, > This isn't about plugins, it's actually about a few helper libraries which > are needed by the main program. There is nothing to say against installing these libraries into $(libdir), although you can also simply link them statically when they are used by only one program (gives you a 5% speed bonus on i386, as shared libraries need one register to point to itself, as they may be mapped to different virtual addresses in different process spaces). > Well, the program used to be a win32-only program, so I would like to keep > everything in place like it used to be, makes things a bit easier for me > (and for the users as well, of which most will probably use the binary > distribution to install the program). It does make things very difficult, rather. Unix people are used to install software by telling it that it is going to be installed into /usr/local, then installing into /some/other/place and symlinking the files over. A typical layout looks like this: /usr/local: drwxrwxr-x root dist DIR drwxrwxr-x root dist bin drwxrwxr-x root dist lib /usr/local/DIR: drwxrwxr-x user dist foo-1.0 /usr/local/DIR/foo-1.0: drwxrwxr-x user dist bin drwxrwxr-x user dist lib /usr/local/DIR/foo-1.0/bin: -rwxrwxr-x user dist foo [which loads libfoo.so.0 without an rpath] /usr/local/DIR/foo-1.0/lib: -rw-rw-r-- user dist libfoo.so.0.1 lrwxrwxrwx user dist libfoo.so.0 -> libfoo.so.0.1 lrwxrwxrwx user dist libfoo.so -> libfoo.so.0.1 /usr/local/bin: lrwxrwxrwx user dist foo -> ../DIR/foo-1.0/bin/foo /usr/local/lib: lrwxrwxrwx user dist libfoo.so.0.1 -> ../DIR/foo-1.0/lib/libfoo.so.0.1 lrwxrwxrwx user dist libfoo.so.0 -> ../DIR/foo-1.0/lib/libfoo.so.0 lrwxrwxrwx user dist libfoo.so -> ../DIR/foo-1.0/lib/libfoo.so You see, the packages are already separated this way, plus everything is sorted like it should be. For example, the prelink program can speed up loading by assigning address slots to all libraries (found in /lib directories) and then adapting the executables accordingly, so you can save the relocation time. Your program would not benefit from that when the libraries are outside of the /lib directory. > Also, it will not get installed into /usr/bin or /usr/local/bin. > /usr/bin/programname would be possible.. (yes, everything needed to run the > program is inside that directory) > (note: /opt/programname will be the default location suggested by the > installation program) Erm, installation program? Don't do that, most admins won't use it anyway, since they cannot control where stuff is installed other than by putting it inside a chroot jail. Believe me, people are glad if you help them by making this a no-surprises installation rather than an easy-for-most-users installation. Who cannot install software that comes in regular packages usually uses prepackaged software in .deb or .rpm format or instructs their sysadmin to install the sw. > You're right, but since I wasn't talking about plugins (see above) the > soname is actually used here. Even then, paths in sonames are not portable and (in most cases) are stripped anyway by the linker. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgp0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Using libtool together with the ${ORIGIN} soname variable
Hi,
> However, I need these plugins to be in the same directory as where the main
> executable resides, and I cannot install them into one of the $blah/lib
> paths or add the current path to LD_LIBRARY_PATH.
This is a bad idea. Most likely, your program will end up in /usr/bin or
/usr/local/bin, and you probably don't want your plugins to be in the
$PATH. You really want .../lib//plugins, aka
$(pkglibdir)/plugins . Trust me, I know what I'm doing.
> When I try to specify this soname using libtool (adding it to the LDFLAGS
> primary, eg. -Wl,-soname -Wl,{ORIGIN}/mylibname.so) it gets overridden by
> the libtool script, which also uses it to set the so name.
The path should not be part of the soname. Actually, the soname is never
used for plugins (it is taken as the name the executable wants to load
at link time).
Simon
--
GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4
pgp0.pgp
Description: PGP signature
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Migrating existing libraries to libtool
Keith, > I maintain a few X libraries and would like to see about transitioning > them from imake to automake. The stumbling block is that I cannot change > the library version numbers across this transition on any operating system. To remain binary compatible, it suffices to have the same major version, as programs are expected to link against the .so. file. Which file this actually symlinks to is irrelevant. So in fact you start off using -version-info :0:0 and then go on as in the libtool manual. > libtool makes this transition system dependent as I must compute the > correct version-info string for each operating system to have the correct > library versions generated out the other end. This is contrary to the > desired goals of libtool. Hrm, how is that solved currently with imake? Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 msg03618/pgp0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC
Robert, > Ok, here it is. This patch changes AC_LIBTOOL_PROG_COMPILER_PIC > so that it only appends -DPIC to the default "C" tag and the CXX > tag for C++. I would also like to deprecate -DPIC in the 1.5 release > to make it clear we intend to do away with it. I would also like > to ask anyone who does depend on this to let us know when/where/why & > how > so we can add a section to the documentation on how to modify > code to not need -DPIC. Inline assembler is compiler dependent anyway. So for inline assembler the correct syntax is #if defined(__GNUC__) && !defined(__PIC__) && defined(__i386) asm( /* Non-PIC asm implementation */ ) #else /* C implementation */ #endif or, respectively #if defined(__GNUC__) && defined(__i386) asm( /* PIC asm implementation */ ) #else /* C implementation */ #endif Perhaps there should also be a small comment why #ifndef __PIC__ is not enough. If you have compiler independent code that you want to conditionally compile depending on the PIC setting, you have a real problem now, since there is no longer a standardized preprocessor symbol, and you cannot work around that. It may be worth investigating whether glibc has such portions (they don't use libtool, but set -DPIC for themselves when compiling the shared library; there are lots of #ifdef PIC in the code) and whether this warrants a check in configure whether we need to set -D__PIC__ in order to get that feature back. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 msg03469/pgp0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC
Robert, > I think you can ignore inline assembler for anything other than > C (including C++). I've never thought about it, but inline assembler > in Fortran code sounds truly frightening! Anyway, if it was so > important, why doesn't the compiler define it for you? Current gcc defines __PIC__ and __pic__ if -fPIC or -fpic is used (this is defined in the specs file), and actually this is the right way to do it, but I fear that people are still using #ifdef PIC because they have seen it defined on the command line and are not aware of __PIC__. What would be needed is a good transition plan. For example, the libtoolize command could list the incompatible changes since the last version. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 msg03467/pgp0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC
Robert, > Ok then, I'll see if I can make "-DPIC" into > a conditionally-set thing that would be set to "" for anything > but C and C++. Can we agree on that? ;) Yes, although it would be nice if the other languages also had a way of knowing they should emit PIC, at least if they allow conditional compilation and/or inline assembler (the most prominent being assembler itself -- I don't know whether everyone uses the gcc frontend to assemble stuff). Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 msg03465/pgp0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC
Hi, > Good point, we never really resolved this issue. > All in favor of dropping -DPIC entirely say "I"! I'm against it. If you have optimized assembler versions of some code for some platforms (like the STL has, for example) and some of that code is not PIC, it is a good idea to enclose it in #ifndef PIC. So dropping -DPIC will remove an useful feature and make everything that uses it miscompile (for some platforms, in a fatal way). Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 msg03463/pgp0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
