Re: Getting filenames for libraries
Jason Curl wrote: I can't move over to libtool 2.2.x just yet (most distros I support still have 1.5.26 - sorry) and I'm generating libraries. FWIW, most distros have a way to use upstream packages without re-libtoolizing and re-autoreconfing them. I'm using Ubuntu 8.04, SuSE 11.0, Cygwin 1.5.x. I'm a little afraid of having both libtool 1.5.x and 2.x installed simultaneously and don't want to uninstall 1.5.x in fear of breaking things. This newsgroup has enough reports about mixing releases, especially libtool. I think what Ralf meant was that you said most distros I support as if to imply that shipping a tarball generated with 2.2 would also require end-users to have 2.2 installed to build it. But the whole point of the make dist tarball is that it's standalone and the user shouldn't need any special developer tools to build it, other than a shell, compiler, and make. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static
Ralf Wildenhues wrote: Did GCC change since then, or is this system-dependent? Interesting. I'd be curious to see if powerpc-ibm-aix5.3.0.0-c++filt recognises the FI/FD encoding, and if so then it would be reasonable to conclude that this is in fact system-dependent or otherwise an internal implementation detail. Nevertheless it seems to me like the regexp ought accept but not require the leading F since the testcase of a simple ctor results in a symbol _GLOBAL__I_.* on Linux as well. Brian
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static
Ralf Wildenhues wrote:
I'm actually not sure whether _GLOBAL__F[ID]_.* can appear on w32.
Do you know? They should happen with C++ code using constructors
and destructors IIRC.
Yes they do occur, although not matching that regexp. For one, they
will have two leading underscores before the G, as with all symbols
compared to their linux counterparts (i.e. __USER_LABEL_PREFIX__ is _
on Cygwin/MinGW.) For another I would have expected the regexp to match
[FID] not F[ID] as there seems to generally be only one character in
that position, whose purpose is illuminated by this comment in
gcc/tree.c:
/* Generate a name for a special-purpose function function.
The generated name may need to be unique across the whole link.
TYPE is some string to identify the purpose of this function to the
linker or collect2; it must start with an uppercase letter,
one of:
I - for constructors
D - for destructors
N - for C++ anonymous namespaces
F - for DWARF unwind frame information. */
A testcase:
$ echo struct foo { int x; foo() : x(42) {}; }; static foo bar; \
| g++ -x c++ -S - -o - -O2
.file
.section.ctors,w
.align 4
.long __GLOBAL__I__77970994_840EDDA1
.lcomm _bar,16
.text
.align 2
.p2align 4,,15
.def__GLOBAL__I__77970994_840EDDA1; .scl3; .type
32; .endef
__GLOBAL__I__77970994_840EDDA1:
pushl %ebp
movl$42, %eax
movl%esp, %ebp
popl%ebp
movl%eax, _bar
ret
Also:
$ c++filt __GLOBAL__I__foobar
global constructors keyed to _foobar
$ c++filt __GLOBAL__D__foobar
global destructors keyed to _foobar
$ c++filt __GLOBAL__FI__foobar
__GLOBAL__FI__foobar
This implies that 'FI' is not valid, or at least not recognised by the
demangler as significant.
Brian
Re: using .la or .a when linking an executable ?
Vincent Torri wrote: No. I wouldn't even know that indirect deps work on w32, or whether they help there. Ok, i'll wait for a mingw dev to answer. It's irrelevant. The option is accepted but silently ignored, because PE doesn't have anything analogous to the ELF DT_NEEDED tag. If you specify a lib on the link command line but no symbols in it are referenced from the program being linked, it's a no-op, so the problem that this option was invented to solve doesn't exist there. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Sticky --disable-shared
Alessandro Vesely wrote: Why not? I can build a shared library linking it with a static one. The static library has to be compiled with -fPIC, of course. It will then be included in the shared one, without further runtime dependencies. Well of course if you put PIC objects in a static archive you can do that. But that misses the point, because it's not a common thing to do and the vast majority of static libs aren't built that way (and certainly not by libtool.) Moreover, libtool has no way of knowing wheter a random archive that's outside of its control happens to contain PIC objects, so it assumes it doesn't which is correct in the vast majority of cases. Now AFAIK libtool will create archives of PIC objects for convenience libraries. But these are never installed and always under the control of libtool so it doesn't have to guess. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Ralf Wildenhues wrote:
Oh well; if somebody digs out the auto-import semantics from the list
archives/manuals, feel free to add a note to export.at so that the next
person won't be confused again. (Extra score for putting it in the new
w32 chapter. ;-)
The first issue here is that the auto-import mechanism requires that the
reference to the imported data item be in a writable section, because it
tricks the OS loader into making the fixup to the data address as if it
were fixing up an address of a dllimported function call.
The second issue is whether --enable-auto-import was specified to the
linker. This is a tri-state setting:
(A) If --disable-auto-import is specified, no auto-import functionality
is attempted and link errors will result unless __declspec(dllimport) is
used with all data references.
(B) If --enable-auto-import is specified then the feature is enabled and
the link script is modified to place the contents of .rdata into .data,
in effect making all read-only data writable.
(C) If neither of the above are specified then the auto-import feature
is still enabled, but the link script is unchanged, and anything in
.rdata stays read-only.
The important point here is where the reference to the data item is
located. Whether the data item itself is const doesn't matter, what
matters is the location from which it's referenced. For the vast
majority of cases, the reference is in code, and so the linker can just
mark .text as writable -- it can do this without modifying the link
script so this works with both (B) and (C).
And this is the case with v8 in export.at, which can be reduced more or
less to the following, which simply shows that the reference to _v8 is
in .text:
$ echo 'extern const char v8[]; char foo() { return v8[0]; }' | \
gcc -x c - -c -S -o - -fomit-frame-pointer
.file
.text
.globl _foo
.def_foo; .scl2; .type 32; .endef
_foo:
movsbl _v8,%eax
ret
In fact the constness of v8 is irrelevant, you get the same output if
you remove 'const'. What does matter is if the reference to it is
const:
$ echo 'extern char v8[]; const struct { char *ref; } s = { v8 };' |\
gcc -x c - -c -S -o - -fomit-frame-pointer
.file
.globl _s
.section .rdata,dr
.align 4
_s:
.long _v8
Here you have the _v8 reference inside this struct that lives in .rdata,
so if you want to auto-import v8 you need to pessimize .rdata to be
writable, and thus you need (B). The nasty part is that auto-import
will still try to do its job in case (C), and the link will succeed, but
you will get an inscrutable STATUS_ACCESS_VIOLATION (0xC005)
exception at runtime from the operating system before the process even
starts. This is what the linker is trying to warn about with the
following diagnostic:
warning: auto-importing has been activated without --enable-auto-import
specified on the command line.
This should work unless it involves constant data structures referencing
symbols from auto-imported DLLs.
N.B. The tri-state behavior is new as of approx 2007-10-01. Prior to
that, passing --enable-auto-import didn't really have much of an effect
other than suppressing info messages that the linker printed. And if
you did have the case where you wanted to auto-import a reference in
.rdata as in the last example, you had no choice but to manually hack
your linker script or remove the 'const'. This changed with the patch
for binutils PR4844:
http://sourceware.org/bugzilla/show_bug.cgi?id=4844.
It's also worth noting that if you do declare v8 as
__declspec(dllimport) then the compiler refuses (with a compile time
error) to let you use its address as a constant initializer as in the
last example. Since this does work on other platforms like ELF, I
suppose you can view this as another portability tradeoff: you gain the
abililty to port this software as-is without having to modify it, albeit
at the cost of essentially making all const data writable and unable to
be shared with other process instances.
On this subject of the politics of declspec markup vs. auto-import, I
guess it breaks down to this:
For auto-import:
Pro: headers need not be modified/uglified to cater to win32-isms
Con: those headers may already have #defines for declarations using ELF
symbol visibility, in which case it's easy to hook in the equivalent
Win32 declspecs
Pro: support ELFisms like using a var from a shared lib as a const
initializer
Con: at the cost of making .rdata writable and unsharable (and a small
startup penalty)
For explicit __declspec(dllimport)
Pro: for function imports, saves an extra jump through the __imp_foo
thunk
Pro: for data imports, retains compatibility with MSVC as well as .text
remaining readonly and shareable
Brian
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin wrote: Ah, ok. That's bad. The misleading name i586-mingw32msvc-gcc caught me. Again. What in the world is msvc doing in there? I believe this is to denote that it defaults to the MSVCRT runtime, as opposed to the very old CRTDLL one, which the MinGW toolchain still provides components for: startup object for executable: crt1.o (CRTDLL) vs. crt2.o (MSVCRT) startup object for shared library: dllcrt1.o (CRTDLL) vs. dllcrt2.o (MSVCRT) import lib for runtime: libcrtdll.a vs. libmsvcrt.a lib supplying aliases of common ANSI functions without underscores: libcoldname.a vs. libmoldname.a So I guess they are just being explicit in their target name so that if they ever wanted or needed to offer a toolchain that defaults to CRTDLL it would not clash. Not that I can imagine anyone wanting that. Brian
extra copy of manual on www.gnu.org
The GNU website has both the current manual: http://www.gnu.org/software/libtool/manual/libtool.html ...as well as this older version from 1.5.24: http://www.gnu.org/software/libtool/manual.html From the similarity of the URLs I'm guessing that this is accidental. Unfortunately search engines have an uncanny habit of finding those old copies and putting them near the top of the results, which leads to a lot of confusion if the neglected version evades deletion long enough such that it documents a long-obsolete version. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: different object sets in shared and static libs
John Calcote wrote: Is there a way to specify additional objects (sources) for the shared library that will not be linked into the static library. You could always wrap the entire contents of the file with #ifdef PIC. The objects would still be in the static lib but they would be essentially empty files. I know, not the cleanest solution. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: v1.5.27a 'syntax error' in numerous packages
snowcrash+libtool wrote: i'm guessing the nomially required rm-ing is somewhere inbetween the two actions; likely at least (just?) the aforementioned 'ltoptions.m4'? If you keep your build dirs around you can do a much better job of surgically removing a package: make install DESTDIR=/tmp/deleteme \ find /tmp/deleteme \( -type f -o -type l \) -printf '/%P\0' | \ xargs -0 rm; rm -rf /tmp/deleteme This simply installs the package again in an empty throwaway dir and uses the resulting filelist to delete from the live system. Of course, you may want to fortify this in various ways: pick a more appropriately named temp dir, make sure it's empty at first, sanity check the list of files to delete, ensure the package supports DESTDIR (vs. prefix overriding) etc. But you get the general idea of the method. Some packages generalize this with a make uninstall rule. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: linking with extern DLLs under Cygwin
Peter Rosin wrote: It is not terribly hard to create those import libraries semi- manually. dlltool can do most of the work. Is that not an option for you? That or simply a symlink libfoo.dll.a - ../bin/cygfoo-n.dll. In the official Cygwin distro all devel packages contain import libs, so I'd consider this a bug in the ICU package if it can't generate one. One can be created as a side effect of linking the DLL simply by adding -Wl,-out-implib,libfoo.dll.a. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Favoring static linking at configure time
Benoit Sigoure wrote:
shared libraries). The first case that comes to my mind is Windows
where there used to be import libraries named in libfoo.a (whereas
they are now named libfoo.dll.a or whatever). But maybe this was a
long time ago so it's not common enough to bother?
Every one of the w32api import libraries is named according to the old
scheme so yes this is still extremely common and won't be going away any
time soon. You really shouldn't have to care what the filename is
though.
2nd problem: when you use -lfoo, GCC (at least) seems to always use
libfoo.{so,dylib,sl,you-name-it} rather than libfoo.a. AFAIK there
is no switch to kindly ask it to use the .a version (what people do
usually is that they pass the full path to the .a on the link command
line).
Of course there is: -Wl,-Bstatic -lfoo -Wl,-Bdynamic
So yeah the general question basically boils down to: is it possible
to test at configure time whether a static version of a given library
is available and ensure that it's used during the build?
I'm not sure how you'd do this with libtool per se, but in general why
can't you just try a test link with -Bstatic -lfoo, if that succeeds
then use that, otherwise fall back to just -lfoo.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Favoring static linking at configure time
Benoit Sigoure wrote: Of course there is: -Wl,-Bstatic -lfoo -Wl,-Bdynamic Hmm I didn't know this. How portable is it? I guess a gccism, but is it even portable across versions/ports of GCC? It doesn't really have anything to do with gcc, it's the linker that interprets these options. -Wl is the only part gcc sees and that has been in gcc forever. I'm not sure if other compilers have options for pass this to the linker or not. -B seems to be fairly portable; all of the following support it: GNU ld: http://sourceware.org/binutils/docs-2.18/ld/Options.html Solaris ld: http://docs.sun.com/app/docs/doc/819-2239/6n4hsf6n2?l=ena=view FreeBSD ld: http://www.freebsd.org/cgi/man.cgi?query=ldapropos=0sektion=1manpath=FreeBSD+6.2-RELEASEformat=html NetBSD ld: http://netbsd.gw.com/cgi-bin/man-cgi?ld++NetBSD-current Irix ld: http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650db=manfname=/usr/share/catman/u_man/cat1/ld.z Looks like Tru64 does not however: http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51_HTML/MAN/MAN1/0180.HTM Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Favoring static linking at configure time
Peter Rosin wrote: to make link.exe select by itself. As Microsoft themselves typically doesn't have any libraries that are available both as dlls and static (do they?), there is no conflict (for them). MS would use foo.lib for They do. But the differentiate them by filename, not by extension. For example the C runtime comes in a number of flavors: libc.lib - single-threaded, static libcd.lib - single-threaded, static, debug libcmt.lib - multi-threaded, static libcmtd.lib - multi-threaded, static, debug msvcrt.lib - multi-threaded, shared msvcrtd.lib - multi-threaded, shared, debug So the last two are really import libs whereas the first four are real static archives. But I think this particular example is a little flawed since most people select one of the above by command line switches (/ML, /MLd, /MT, /MTd, /MD, /MDd respectively). [ There's a similar set for the C++ runtime and the mixed managed/native runtimes as well, see http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx. ] Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows DLLs from Unix with minimum effort
Jason Curl wrote:
For Posix systems I agree (and I haven't had to care until now). It's an
unnecessary burden for w32api however, especially for users that don't have
any kind of sane build environment. I guess I'm saying I don't know how to
package the result so that someone on w32 can use it on a standard cmd.exe
console without having Cygwin, etc. installed. This environment is only
necessary for the build.
The wrapper is totally irrelevant to end users, it is only for the
convenience of the developer to be able to run the binary uninstalled.
To make a binary package to give to end users you do the exact same
thing that you would on a POSIX system to create a binary package:
make install DESTDIR=/some/staging/area
# or make install prefix=/some/staging/area
(cd /some/staging/area tar jcf binary-package.tar.bz2 *)
[ aside ]
The choice of whether you use DESTDIR or override prefix is mildly
controversial. Some hand-written makefiles don't support DESTDIR, and
DESTDIR doesn't play nicely if you're using Win32 paths because you
can't prepend something in front of a drive letter to produce a valid
path. But if you use automake you automatically get DESTDIR support, so
it's fairly common, as well as being a part of the GNU coding standards
spec.
On the other hand overriding prefix normally doesn't require any special
makefile support, other than the invariant that overriding it must not
cause anything to be rebuilt (which is also specified by the GCS.) It
also is the only route if you're using Win32 paths since they can't be
prepended. But I don't personally like it because it becomes clumsy if
you have specified more than just --prefix at configure time (and they
aren't subdirectories of prefix that can use ${prefix}). For example if
I am making binary packages for a typical distro, I might configure
with:
path/to/configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
Now I've built and want to install to a staging area in order to create
the binary package. If I use DESTDIR, I can simply:
make install DESTDIR=/tmp/mypackage
...and the entire tree as originally configured will install under that
staging area. However if I want to use the override technique I must
remember all of the options that I originally specified and be sure to
override them all appropriately:
make install prefix=/tmp/mypackage/usr sysconfdir=/tmp/mypackage/etc \
localstatedir=/tmp/mypackage/var
So not only is it more typing, but I've duplicated my configuration in
two places which can easily get out of sync. This is not a concern in
the common case where only --prefix was given, since all the other paths
have defaults that symbolicly reference $prefix, e.g.
exec-prefix='${prefix}' and bindir='${exec-prefix}/bin' and
libdir='${exec-prefix}/lib' and so on, so they will take the correct
values when only prefix is overridden. And in fact if you can specify
these as subdirectories of prefix or exec-prefix or whatever it's
advisable to continue to use this syntax so that you can simply override
prefix and have everything else follow. But as I said I simply find
DESTDIR a cleaner solution that involves less worry.
[ end aside ]
To cater to the typical Win32 user you might want to flatten the
heirarchy, since they are typically used to having everything in one
dir, so e.g. --bindir='${prefix}' --libdir='${prefix}'
--docdir='$[prefix}' (and so on for a million other variables) which
would result in the binary-package.tar.bz2 created above simply being a
flat set of files. But I guess it all depends on your target audience
and how you plan to distribute things (e.g. NSIS, InnoSetup, 7-zip sfx,
.zip file, whatever.)
Or should I revert to a different build environment? This is my first attempt
at using Autoconf to build something for native Windows (mostly because I
want to use it on Linux, but other colleagues of mine benefit from it's use
on Windows).
Using Cygwin to build MinGW executables is common but suboptimal.
Unless you really know what you're doing it's very easy to shoot
yourself in the foot: for example you might leak POSIX paths from the
build/configure system into a header or configuration file (or other
generated file), which the resulting binary will be clueless about since
it's a native MinGW app that only speaks Win32 paths. I'd recommend
using MinGW+MSYS instead if you don't intend to build Cygwin programs.
Also relocatability is a whole other ball of wax that you have to
address when building for MinGW, because the user expectation is that
they can install the files in any location -- as opposed to Cygwin where
you have a mount table that handles that bit of indirection and presents
a uniform filesystem layout despite the actual location on disk.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows DLLs from Unix with minimum effort
Jason Curl wrote: libtest.exe -- Doesn't seem to work? No idea what this is... libtest .libs/ libtest.exe-- Will work when libmofo-1.dll is in the path, e.g. copied to this dir. Can anybody explain what libtool is doing?? It appears to do a lot of nifty stuff, but I don't see any dependencies on libmofo from libtest.exe in either case. I'll attach a minimal example when I'm back at work tomorrow. It is a wrapper to allow running the uninstalled binary in the build tree without having to mess with PATH or LD_LIBRARY_PATH or whatever. On a POSIX system this would be a shell script. I think that in libtool HEAD, it won't have such a confusing name. And the directory it runs from (.libs) indicates it is actually the source lt-libtest.c that relies on a shell, so as soon as I move the executable to a virgin computer without Cygwin, the program libtest.exe won't work. You shouldn't be manually mucking about like that, you use make install to get an installed copy and that will not be a wrapper. If you configured with CC=gcc -mno-cygwin (i.e. used this fake mingw setup) then the Cygwin dependence should only be for the wrapper which isn't supposed to be installed or even moved out of the build directory for that matter. I'd also like to generate .lib files (what is the .a file that is generated anyway? Is that the .lib import library?) An import library can be named foo.lib, libfoo.a, or libfoo.dll.a; they are all the exact same thing just named differently. Don't confuse the libfoo.a name with a static library which has the same style name but is a totally different thing (and that's why it's considered deprecated to name an import library libfoo.a, but some are still done that way, e.g. all of w32api.) Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows DLLs from Unix with minimum effort
Jason Curl wrote: ./configure CC=gcc -mno-cygwin LDFLAGS=-Wl,--kill-at --target=i586-pc-mingw32 --disable-static on Cygwin to generate the Windows DLL Target is not the right thing to use here. Target only has meaning in the context of building tools that themselves generate code, such as compilers, linkers, assemblers, etc. If you want to simply indicate that you are cross-compiling a library for a host different than the current one then you use --host. Also, if you're going to use Cygwin as a Fake mingw then you probably also should use --build=mingw as well. I have also another subdirectory that tests the library but I can't link to it using mingw. First it doesn't recognise that the name was simplified (it looks for [EMAIL PROTECTED] for example instead of _my_func/my_func). You need to understand that the --kill-at is a linker option. It cannot change behavior of the compiler, and when gcc is told to use the stdcall calling convention for a function, it includes the normal stdcall decorations on the symbol. There is no way to change this AFAIK, unless you use __attribute__((alias)) or something. So if you want to use these symbols without the stdcall decoration, then you have to get the linker to jump throuh hoops. --kill-at removes them from names that are exported, but that still doesn't change the fact that the compiler emits calls to the decorated names. For that you will have to use --enable-stdcall-fixup, which will link calls to [EMAIL PROTECTED] to _foo if there is no [EMAIL PROTECTED] found anywhere. Or, you could create an import library and link with that. But instead of all of that I think I would just simply use --add-stdcall-alias. This should result in both a decorated and undecorated alias of each symbol being exported, so you don't have to try to pretend that gcc isn't emitting calls to decorated names when it really is. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking with libtool mingw
Robert Schwebel wrote: Info: resolving _deflate_copyright by linking to __imp__deflate_copyright (auto-import) Info: resolving __dist_code by linking to __imp___dist_code (auto-import) Info: resolving __length_code by linking to __imp___length_code (auto-import) Info: resolving _z_errmsg by linking to __imp__z_errmsg (auto-import) These are completely normal if you are porting software that does not explicitly dllimport symbols. They are not errors. etronix-Wireshark-trunk-Win/build-target/wireshark-0.99.6/.libs/wireshark.exeS.c:(.data+0x9a4c): undefined reference to `_g_module_name ' .libs/wireshark.exeS.o:/some/path/wireshark-0.99.6/.lib s/wireshark.exeS.c:(.data+0x9a5c): undefined reference to `_g_module_open' .libs/wireshark.exeS.o:/some/path/wireshark-0.99.6/.lib s/wireshark.exeS.c:(.data+0x9c4c): undefined reference to `__g_async_queue_get_mutex' .libs/wireshark.exeS.o:/some/path/wireshark-0.99.6/.lib ... collect2: ld returned 1 exit status There is not enough information to help you based only on the error. We need to see the full link command, at least. It would also be helpful to know what object or library contains the symbols that are listed as undefined. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Why is setting LD_LIBRARY_PATH very bad?
Wintaki Hagabashi wrote: - Perhaps it is possible to create a replacement library that some suid application uses and you can then gain root access (maybe there are other things stopping this from happening?) On linux at least, LD_LIBRARY_PATH is ignored when invoking something that has the setuid or setgid bit. - Big pain when developing, have to make sure your LD_LIBRARY_PATH is always set correctly, pointing to your build area. And then if you have multiple checkouts (perhaps working on a branch), you need to keep changing your LD_LIBRARY_PATH. But this is the libtool list, and the above is exactly the kind of tedium that libtool takes care of for you so that you don't have to worry about it. Having said that, I don't see what the problem is really in a controlled environment with production installations? Again, using my Oracle example, there is no way they could force you to install into a special place. They require setting LD_LIBRARY_PATH. Obviously you don't want every single utility and application installed having its own special lib dir, but isn't that the normal thing to do for large(r) software distributions? Especially commercial software? And what is a real problem is when you do need to move a package. THen the rpath can cause a big headache for you depending on the situation. If you ask me, these binary packages should either: A. Play nice with the existing package management system of the distro by shipping in a .deb/.rpm/whatever package that: - installs to the system locations like /usr/lib, /usr/bin, /usr/share, etc. - allows clean install/uninstall/upgrade/remove using the familiar package manager commands - captures the library dependencies of the software so that all required support items of the required versions are also automatically installed - prevents accidents like the user running routine security updates from the distro which installs an incompatible version of some lib because the binary software's requirements were not communicated to the package management system (i.e. the general principle of: don't mess around behind the back of the package management system, it's there to help you, not something that gets in the way.) or B. Ship with an install script that updates /etc/ld.so.conf to add the required paths. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool woes
Jason Curl wrote: I guess what happens if I don't say this the build will fail. I've It should produce static libraries if it cannot produce shared ones. turned it on and it looks good. I'll try and search more info later, but while I'm at it: - Why is it .dll.a and not .dll? - How is versioning information embedded in the DLL, or is the basis of the DLL hell? .dll.a is the import library. .dll is the actual library. Both should be produced. The import library is used when linking against the library, but it is not needed at runtime and contains no code. It's typically distributed in the same context as headers -- it is needed by developers who want to build against your library, but not users who simply want to run software that uses your library. In some cases it is also named just libfoo.a, or perhaps foo.lib if you want compatibility with users of the MS toolchain. As its name suggests this is actaully an ar archive. It looks like you may be getting confused because the linker outputs a message along the lines of creating file libfoo.dll.a when the --out-implib linker switch is used, but this really means in addition to the normal output libfoo.dll I'm also producing an import library libfoo.dll.a as a side effect of creating the library not that the library would actually be named libfoo.dll.a. The concept of an import library is a bit of a hold-back to days past. Using the GNU linker at least, you can link directly to a DLL without any import library. However, there is one function of an import library that cannot be duplicated otherwise, and that is the ability to provide aliases for symbol names. This allows you to do things like rename functions in the actual library without affecting callers/users that use the old name. It also comes in very handy when reconciling differences in stdcall function decoration when trying to mix code between different vendors' toolchains. PE has no means of explicit symbol versioning. Shared library versioning works on the basis of choosing an appropriate filename for the library, i.e. libfoo-n.dll. This should happen automatically when you use -version-info appropriately. The import library thus also provides one further function that makes it very handy -- it functions analogously to the foo.so - foo.so.1 symlink on POSIX systems. The import library is always named just libfoo.dll.a without any version numbers, and so the linker finds it when you specify -lfoo. However, the actual name of the library may be libfoo-2.dll (or cygfoo-2.dll if you're using Cygwin) and hence the import library is the thing that selects which version of the library to link against. For example on Cygwin: $ ls -l /usr/bin/cygintl* /usr/lib/libintl* -rwxr-x---+ 1 brian Users 22K Dec 13 2001 /usr/bin/cygintl-1.dll -rwxr-x---+ 1 brian Users 37K Aug 10 2003 /usr/bin/cygintl-2.dll -rwxr-x---+ 1 brian Users 31K Nov 19 2005 /usr/bin/cygintl-3.dll -rwxr-x---+ 1 brian Users 31K Oct 22 2006 /usr/bin/cygintl-8.dll -rwxr-x---+ 1 brian Users 48K Oct 22 2006 /usr/lib/libintl.a -rwxr-x---+ 1 brian Users 30K Oct 22 2006 /usr/lib/libintl.dll.a -rwxr-x---+ 1 brian Users 800 Oct 22 2006 /usr/lib/libintl.la Here you see that there are four versions of the libintl library installed, however there is just the one import library. The name of the DLL is encoded into the import library, so this means any new code that is compiled today with -lintl will find /usr/lib/libintl.dll.a which internally specifies the filename corresponding to ABI version 8 of the library. But the other versions can still exist on disk for the sake of supporting existing binary packages of the previous ABI versions. So this works just like the symlink on POSIX that selects which version of the library all new binaries should link against (which is almost always the newest.) Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool woes
Jason Curl wrote: /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -version-info 0:0:0 -o libtp.la -rpath /usr/local/lib version.lo libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries Libtool won't build shared libraries on Win32/PE targets without -no-undefined in *_LDFLAGS. The text of this warning message could perhaps be clearer, because it's not telling you that you necessarily have any undefined symbols, it's telling you that you didn't assure libtool that you don't. lib -OUT:.libs/libtp.lib version.o ../libtool: line 5973: lib: command not found I'm not sure why it's trying to use lib here, that seems wrong if you're using gcc/binutils. Possibly a configure problem? Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Making shared libraries (DLLs) on Windows: -no-undefined
John Brown wrote: Running 'nm --undefined-only libamrnb-2.dll' gives: U ___crt_xc_end__ U ___crt_xc_start__ U ___crt_xi_end__ U ___crt_xi_start__ U ___crt_xl_start__ U ___crt_xp_end__ U ___crt_xp_start__ U ___crt_xt_end__ U ___crt_xt_start__ U ___tls_end__ U ___tls_start__ U __end__ If undefined symbols are not allowed, then what's that? Those are labels created by the linker script. They represent locations, not data. You can refer to them in your C code only as __foo__, never as __foo__. I don't know why they are marked U. In any case, this is not at all the same situation as function or data imports. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Making shared libraries (DLLs) on Windows: -no-undefined
Bob Rossi wrote: Yup, I think this is the topic that I've been asking about. Not that I don't like it, but some of the users of a library I help maintain don't like it. I don't seem to have an easy way to make libtool just output the name of the dll with out the -number. I don't see why you can't just use -avoid-version. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Making shared libraries (DLLs) on Windows: -no-undefined
John Brown wrote: In all cases, ld would find the symbols easily, if only it would try. Is libtool really complaining about these so-called undefined symbols? If that is so, why? Why does it not just try to build the DLL? If ld fails because of undefined symbols, then it can say so at that time. Is that if I am building my.dll on Windows, and it consists only of my.c, which calls only functions in my.c, then -no-undefined is not required, but otherwise, -no-undefined is necessary? Should I tell the libamrnb maintainer that configure needs to add --no-undefined on Windows, or Windows users should configure with LDFLAGS=-no-undefined? Libtool will *not* create shared libraries without -no-undefined on PE targets, period. It's not about it trying to detect whether there are or are not any undefined symbols, it's about the maintainer telling libtool that it is safe to assume or not assume something. So yes, you need to either use -no-undefined unconditionally, or conditionalized on PE targets. See http://article.gmane.org/gmane.comp.gnu.mingw.user/18727 for a little of the history. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] New library type needed?
Charles Wilson wrote: I have a library that I want to build shared (let's call it libbfd). It depends on a portability library that is currently built as a non-libtool, static library (let's call it libiberty). g I completely understand the motivation for the meat of this, speaking in the hypothetical sense, but why would you ever want to build libbfd shared? It is always built static by default even on ELF systems, for the same reason as libiberty - it is not expected to expose anything resembling a stable or maintained ABI. And its maintainers do not want the burden of having to maintain an ABI given its history of not being designed as such. So it seems like a really bad idea to jump through hoops to make it shared, as you'd end up with the situation you mentioned dozens of cygbfd-long string.dll files to satisfy all the various consumers. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem with libtool's choice in library_names= under MingW port- .dll.a and .lib not the same!
Ed Hartnett wrote: My C library builds fine, but when it tries to build the very first test, it fails, because it tries to link to libnetcdf.lib instead of libnetcdf-4.dll. This is strange to me. I don't understand why, under MingW, this works: gcc -g -O2 -o .libs/t_nc.exe t_nc-t_nc.o ./.libs/libnetcdf-4.dll -L/usr/local/lib And this doesn't: gcc -g -O2 -o .libs/t_nc.exe t_nc-t_nc.o ./.libs/libnetcdf.lib -L/usr/local/lib When libnetcdf-4.dll and libnetcdf.lib are copies of each other. In fact, the names has to end with .dll or the link fails. Here's the versions of gcc and ld: Something is horribly wrong if the .lib is the same as the .dll. That is not how it works. The .lib file is supposed to be an import library, same as the .dll.a file. They are just two different names for the exact same thing. I don't know why you're bothering with a .def file, either. You can simply do -Wl,--out-implib,foo.dll.a to have the import library created at the same time as the .dll. You can rename/copy foo.dll.a to foo.lib if you want for MSVC people, they are exactly the same thing. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: windows static archive, missing symbols
Howard Chu wrote:
That's false. It's just an address relocation, performed by the runtime
linker. Writing code that requires XXX_STATIC macros is nothing but
ignorant, and hasn't been necessary for at least 5 years.
You know I did actually test this before posting. Go on, do a hello
world that calls a dllimported function. Here is the testcase I used:
#include stdio.h
void foo(void);
int main()
{
puts(main);
foo();
}
Without any __declspec on the declaration to foo, the disassembly in the
debugger is:
6 {
0x401050main: push %ebp
0x401051main+1: mov$0x10,%eax
0x401056main+6: mov%esp,%ebp
0x401058main+8: sub$0x8,%esp
0x40105bmain+11: and$0xfff0,%esp
0x40105emain+14: call 0x401090 _alloca
0x401063main+19: call 0x401120 __main
7 puts(main);
0x401068main+24: movl $0x402000,(%esp)
0x40106fmain+31: call 0x401130 puts
8 foo();
0x401074main+36: call 0x401080 foo
9 }
0x401079main+41: leave
0x40107amain+42: ret
And note that 0x401080 foo is the import stub that calls __imp_foo:
0x401080foo: jmp*0x404098
Now, add the __declspec(dllimport) and recompile. This is what you get
now:
6 {
0x401050main: push %ebp
0x401051main+1: mov$0x10,%eax
0x401056main+6: mov%esp,%ebp
0x401058main+8: sub$0x8,%esp
0x40105bmain+11: and$0xfff0,%esp
0x40105emain+14: call 0x401090 _alloca
0x401063main+19: call 0x401120 __main
7 puts(main);
0x401068main+24: movl $0x402000,(%esp)
0x40106fmain+31: call 0x401130 puts
8 foo();
0x401074main+36: call *0x404098
9 }
0x40107amain+42: leave
0x40107bmain+43: ret
Note that here you get a direct call to the .idata location of the
imported address (__imp_foo aka 0x0404098) without the extra call.
So, no, it is not the same to omit dllimport, there is a (small) speed
penalty. And there was recently a patch posted and applied to binutils
that will eliminate these stubs if they are not necessary so once you
upgrade your binutils there will be a size penalty to not using
dllimport also.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: windows static archive, missing symbols
Bob Rossi wrote: I know the symbols are in the library because nm tells me so, $ nm -g /home/bobbybrasko/download/pcre/pcre/install/lib/libpcre.a|grep compile libpcre_la-pcre_compile.o: 5550 T _pcre_compile Note here that this is just a regular symbol, as you would expect with a non-shared library. -I/home/bobbybrasko/download/pcre/pcre/install/include C:/WINDOWS/TEMP/ccgGAsIC.o(.text+0x2e): In function `main': C:/msys/1.0/home/bobbybrasko/download/pcre/pcre/build/tmp/test.c:13: undefined reference to `_imp__pcre_compile' But here you're trying to dllimport the symbol. But you don't want to do that in the case of static linking. You'll have to look at the header and see how the dllimport/dllexport is #defined, usually it means you have to add some extra -DSTATIC or similar when you are using the static archive so that the prototypes are not defined dllimport. If libpcre is a libtoolized library and you used libtool to compile instead of invoking gcc yourself it should take care of this for you, though. That's kind of the whole point of libtool, to abstract this away. Does anyone understand why I'd be getting these errors? Are .def files important for static windows libraries or only for dll's? Any advice? AFAIK .def files have absolutely nothing to do with static libraries, which are just collections of .o files really. A .def file is used to express what symbols a given .dll exports and imports, but these concepts don't even exist in the case of a static library. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Absolute paths generated by libtool.
Duft Markus wrote: Additionally cygwin does not correctly work on SMP machines with win2k or higher. Need a shovel for that FUD you're slinging? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool/ltmain linking wrong stdc++
Taj Morton wrote: I was hoping for a solution that maybe involved sedding the libtool file, or something like that. If I can't acomplish it that was, I guess I can just modify Autopackage's wrapper around gcc/g++ to link the compilers libstdc++.so. Can't you just build+install a private version of libkdecore with gcc 3.2, and then ensure that that one is found when building your lib by specifying CXXFLAGS/LDFLAGS as appropriate? Or put another way, if you're going to do the build everything with two separate toolchains thing then doesn't that mean you have to extend that logic to building not just your app/lib but all dependant libs that are referenced in the final app? It seems like it would be a lot easier just to have a chroot or vmware type setup, with gcc-3.2/libstdc++.so.5/whatever-other-libs-of-that-era all segregated so that no modern libs pollute the build. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool + MinGW
Brendon Costa wrote: Question: Does libtool 1.5.22 for MinGW support shared libraries and using DLOpened modules without dlpreopening? Of course it supports shared libraries. If so in the example i gave before for a shared library was created using ar cru and not g++ -shared and was linked into the app as a static library. No, your example was flawed because it did not pass -no-undefined, which means you get static libraries unconditionally. If you fix that, then libtool builds both shared and static versions of the library, and it successfully links against the shared library libshared-0.dll. The only one of the four that fails to build is the static plugin version, which dies with the duplicated symbol problem. $ ls -l total 1737 -rwxr-xr-x1 brianAdminist 588238 Jun 11 19:08 LTDLOpened-0.dll -rw-r--r--1 brianAdminist 119454 Jun 11 19:08 LTDLOpened.a -rw-r--r--1 brianAdminist 7902 Jun 11 19:08 LTDLOpened.dll.a -rw-r--r--1 brianAdminist 819 Jun 11 19:08 LTDLOpened.la -rwxr-xr-x1 brianAdminist 585327 Jun 11 19:08 libShared-0.dll -rwxr-xr-x1 brianAdminist 465800 Jun 11 19:08 libltdl-3.dll -rwxr-xr-x1 brianAdminist 606208 Jun 11 19:08 libtool_test.exe -rwxr-xr-x1 brianAdminist 589161 Jun 11 19:08 libtool_test_np.exe -rwxr-xr-x1 brianAdminist 591364 Jun 11 19:08 static_libtool_test_np.exe I guess i assumed that MinGW platform supported shared libraries using DLL's. If not are there any plans for this in the future? Mingw would be quite useless if shared libraries did not function. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool + MinGW
Brendon Costa wrote: Would someone be able to have a look at the script file and let me know what i am doing wrong? I'm not sure why you are getting the link errors about duplicated symbols, but your testcase in general is not doing what you think it's doing. You'll note that there is not a DLL created anywhere, and this is because you didn't use -no-undefined. On win32 systems this is required to generate shared libraries, owing to the fact that the windows dynamic loader cannot do lazy linking -- all referenced symbols must be resolved at link-time. Without this flag libtool cannot assume that you've met this condition, and so it cannot do anything but create a static library, even if it was told to make a shared lib. The message libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries when creating libShared and libLTDLopened indicates this. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: g++ linking problem
S3 wrote: I see other messages similar to this in the mailing list, but I don't see any resolution yet. I am having a problem linking C++ programs. (I have attached the logs from compiling MySQL and KDE arts.) The programs compile just fine, but when it tries to link them, it fails to find all basic C++ symbols, such as those from libstdc++. I have libstdc++-v3 installed. When I use g++ ordinarily, it links to libstdc++ just fine. Specifically, it can't find: __cxa_pure_virtual std::basic_string This is usually caused by the user trying to link by invoking gcc instead of g++ when C++ code is involved. If you link with g++ it knows to include all the necessary flags and options to support C++, which does not happen when invoked as gcc. However, in your case, libtool is being used which adds another layer of indirection on top of things. Unfortunately your configuration (or perhaps the package itself) is invoking libtool --silent, which means that the libtool wrapper isn't printing the actual command that it's executing, which means those tens of thousands of lines of spew you attached are more or less useless for determining the actual problem. You could have saved everybody reading a lot of time by just incluing the the part that causes the error, which was: /bin/sh ../libtool --silent --tag=CXX --mode=link g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -march=pentium4 -O2 -pipe -fomit-frame-pointer -mmmx -msse2 -fstack-protector -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -ftemplate-depth-99-o libmcop.la -rpath /usr/kde/3.5/lib -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined -version-info 1:0 -L/usr/kde/3.5/lib -L/usr/qt/3/lib -L/usr/lib [many .lo files] -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0 ../libltdl/libltdlc.la .libs/buffer.o: In function `Arts::Buffer::readString(std::basic_stringchar, std::char_traitschar, std::allocatorchar )': buffer.cc:(.text+0x6c1): undefined reference to `std::basic_stringchar, std::char_traitschar, std::allocatorchar ::assign(char const*, unsigned int)' In any case, this is not the right list to post on. I suggest you post this to the libtool list (CC:d), or the mailing list of the package itself. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: trying to build with MinGW under cygwin, but no luck, can't find dllcrt2.o
Ed Hartnett wrote: First, a note: the Cygwin list generally does not like to field questions about -mno-cygwin because when doing so you are using another project's toolchain, and so it's kind of off-topic. However, I think your problem is actually build-environment related and not gcc related, so I will continue, with reply-to set to the libtool list. I am trying to build my libtool-based library package on Cygwin, with the -mno-cygwin option. However, I am getting the following problem: libtool: link: cc -shared .libs/attr.o .libs/ncx.o .libs/putget.o .libs/dim.o .libs/error.o .libs/libvers.o .libs/nc.o .libs/string.o .libs/v1hpg.o .libs/var.o .libs/posixio.o -Wl,--whole-archive ./.libs/libnetcdf2.a ../fortran/.libs/libnetcdff.a -Wl,--no-whole-archive -mno-cygwin -o .libs/cygnetcdf-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libnetcdf.dll.a /usr/bin/ld: dllcrt2.o: No such file: No such file or directory collect2: ld returned 1 exit status make[2]: *** [libnetcdf.la] Error 1 make[2]: Leaving directory `/cygdrive/c/netcdf-3/libsrc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/c/netcdf-3' make: *** [all] Error 2 I am trying to figure out what is wrong. Does anyone have an easy answer for me? Something here looks rather broken. First, a non-cygwin DLL should never be named cygnetcdf-1.dll because the prefix cyg is specifically used for this purpose, i.e. so that they are never found by non-Cygwin apps. A mingw DLL should be named libnetcdf-1.dll. So this makes me think libtool is confused and thinks you're trying to build a native package. Second, dllcrt2.o is a mingw startup file and should be present in /usr/lib/mingw. If not then you certainly have an installation problem. Confirm that you can compile and link a hello world program with gcc -mno-cygwin before continuing. It would help if you would post more details, such as how you configured the package. When trying to build a mingw package under Cygwin you are in effect cross compiling, so the configury should probably look something like the following, although there are many ways to skin a cat: ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin CC=gcc -mno-cygwin (And if you use C++ then CXX=g++ -mno-cygwin, and so on.) Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: questions about DLLs built with libtool - multiple output files...
Ed Hartnett wrote:
-rw-rw-rw- 1 ed root 1043050 Jun 1 07:44 libnetcdf.a
-rw-rw-rw- 1 ed root 360432 Jun 1 07:44 libnetcdf.dll.a
-rw-rw-rw- 1 ed root 632482 Jun 1 07:44 cygnetcdf-1.dll
libnetcdf.a is the static archive for static linking, and gets placed in
/usr/lib.
libnetcdf.dll.a is the import library for the DLL and also gets placed
in /usr/lib. This is what the linker will actually find when the user
specifies -lnetcdf to link, and it essentially just contains a list of
the functions that the DLL exports -- it does not contain any code.
Both of the above are developer files only needed at link time, not
runtime.
cygnetcdf-1.dll is the dynamic library itself and gets placed into
/usr/bin. This is important because on Windows there is no RPATH
embedded in the library. Instead the search order is pretty much just
current directory then PATH, with a couple of really obscure
modifiers. This means that DLLs have to be in the PATH, and /usr/lib is
not typically in the path, but /usr/bin is.
Recent versions of ld can link against DLLs directly without needing an
import library, but the traditional way is to include them. This is an
important distinction when you have multiple ABI versions hanging around
-- for example, there might be cygnetcdf-{1,2,3}.dll installed in
/usr/bin to support compiled binaries of various vintages. However, the
import library filename is not versioned, and there is only a singular
one on the system, typically of the current/latest ABI.
There are also some things (such as symbol aliasing) that can only be
achieved with an import library that are not possible by directly
linking to a DLL. There is a section in the ld manual that explains
this.
Which one do I give to the user as the dll for the library.
Also, I seem to recall reading that it was possible to generate dlls
which either did or did not depend on the cygwin dll being present on
the machine. True?
It is possible, but it's not quite that simple. There are essentially
two separate toolchains: cygwin and mingw. Cygwin implements its own C
library and POSIX emulation layer (cygwin1.dll), whereas mingw targets
the existing Microsoft-provided C library (MSVCRT.DLL) and provides
essentially zero compatibility/emulation layering.
The tradeoff here is that most posix source code can be compiled
unmodified under Cygwin at the cost of a dependancy on cygwin1.dll.
With Mingw there is no dependance on emulation libraries, however there
is often significant porting work to be done because MSVCRT includes
*very* little of the posix API beyond the minimum required by C89. For
example, fork() and exec() flat out do not exist, and signals are so
crippled as to not exist (see
http://marc.theaimsgroup.com/?l=mingw-usersm=114338148907578w=4 for
details on this.) And when using sockets you must use the Winsock API,
which is very similar to the posix socket API, but has some gotchas
(e.g. socket handles are not regular fds and so you can't mix and match
files and sockets in a select().) In summary, when using Mingw you
typically must target -- or at least be aware of -- the Windows API to
accomplish most nontrivial tasks.
Cygwin's gcc provides the necessary framework for using both toolchains
at once, via the -mno-cygwin switch, which is what you are probably
referring to. So it is true that under Cygwin you can create a DLL that
does not depend on cygwin1.dll by simply using -mno-cygwin. However, it
does not just magically remove this dependancy, it switches the compiler
to a very different toolchain, with an associated set of issues as
explained above. This means it's not a magic bullet that can just
surgically remove Cygwin without any other changes.
Also be aware that you can't mix and match cygwin and mingw object files
in a given project, as these two toolchains have entirely different C
runtimes. Invoking -mno-cygwin switches over a completely different set
of system headers and link options, so you should really treat them as
two different compilers. In other words, if you configure with CC=gcc
-mno-cygwin, do it in its own build tree away from the Cygwin build
tree, just as if you were cross compiling.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: hardcode_libdir, rpath and DLLs
Robert Szeleney wrote: Unfortunately, PE DLLs don't support this --rpath option. Is there any way to tell libtool to use something different for this? Probably using LD_LIBRARY_PATH. Though I think that this will not really work, because whenever you execute glib-genmarshal one would have to set this path. (Inside the make process this may not be really a problem, but when executing directly from the shell no one has set this path yet). How does cygwin deal with this? Does this even work on cygwin? Win32 doesn't have any such notion of LD_LIBRARY_PATH, so that is not an option. The DLL search rules are very simple, I think it's essentially 1. current working directory, 2. $PATH, 3. Windows system directory. There may be other obscure modifiers too. The full search order is documented on MSDN under the LoadLibrary() function I think. I suspect the right way to handle this would be to use libtool --mode=execute to run the binary, and that should either set the working directory to the dir where the DLL lives or set $PATH. Or maybe libtool uses a wrapper script for the binary. [ Note that Cygwin does actually support LD_LIBRARY_PATH but only when doing dynamic runtime loading of a library with dlopen(), but it can only do this because at that point Cygwin is fully in control of things and can fake it. When simply calling on the operating system to load a binary (in the case of ./foo) there is no way to influence the DLL search process since that is done by the Windows dynamic loader. ] Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Unhelpful behaviour on Cygwin when file isn't installed
Olly Betts wrote: I don't think there's an obvious dependency cygwin could add to help this (unless perhaps something rather arbitrary like making 'make' depend on 'file'). So libtool (or rather packages it generates) probably does need to cope with file not being installed (or perhaps just check for it in configure and get the user to install it). I think for now I'll just add such a check to my project's configure. In that case adding 'file' to the 'Devel' category might help, since people seem to like to add whole categories. Although a configure check or some kind of fallback would be best. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Unhelpful behaviour on Cygwin when file isn't installed
Ralf Wildenhues wrote: The user who reported this to me says that cygwin doesn't come with file by default either (he'd installed it very recently, so I guess he probably has the latest release). I'm a little suprised by this, but don't have cygwin myself so I can't check if this really is the case. Cygwin is very configurable. So you can probably choose to (un)install file, independently of other choices. Yes, 'file' is in its own individual package so it can be selected/deselected at will. However this package is not in the category 'Base' which means if you just fire up the Cygwin setup utility and accept the default set of packages it will not be installed. However, the 'Base' category includes essentially no development tools (gcc, binutils, make, perl, etc are absent) so it is not intended as a functional starting point for anyone doing development. On the other hand, it would be very easy for someone to select the majority of development tools and still neglect to install 'file'. This is exacerbated by the fact that it is in the category 'Utils' and not 'Devel' so even if you select all of 'Devel' you won't get it. If libtool currently displays somewhat degraded or broken behavior without 'file' then it would be a good idea to at least add 'file' to this 'Devel' category in the Cygwin package DB. This would be a rather simple change and I don't think there would be much trouble getting it done. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Slow shell script execution on Cygwin
Tor Lillqvist wrote: Hmm, but I guess the fork/exec separation makes this harder, Cygwin can't know when it is emulating fork() whether the child process will immediately exec() one of the above. Or does the Cygwin shell(s) already have some special code instead of plain fork()/exec()? I believe that Cygwin's ash used to be compiled to use vfork(), which apparently is faster by some degree under Cygwin. (I don't know the details here.) However as of the last[*] ash release on 2004-01-27 this has been changed so that it's back to standard fork/exec. It seems clear that Cygwin would benefit from some kind of special casing in the shell because of the fork penalty, but apparently no one has the time or is capable of providing this, if it's even feasible. [*] http://marc.theaimsgroup.com/?l=cygwinm=107520010817415w=2 Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Slow shell script execution on Cygwin
Brian Dessent wrote: It seems clear that Cygwin would benefit from some kind of special casing in the shell because of the fork penalty, but apparently no one has the time or is capable of providing this, if it's even feasible. Uhh, nevermind. Upon checking it seems that all the old vfork stuff has been ripped out and not used for some time, and vfork = fork. So it really doesn't matter what the shell tries to do, it looks like expensive fork is going to be called regardless. :( Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
