libtool --config problem resolved

It seems that the problem I was having is the result of not re-libtoolizing the package directory. This apparently caused a mismatch that created the "bug". Sorry about the noise. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfr

libtool --config broken

>From libtool checked out from the multi-language-branch as of today, libtool's --config option no longer produces any output. This breaks part of ImageMagick's build environment since certain options are tested to support conditional portions of the Makefiles. Any ideas? Bob ===

Re: dll compile, can not resolve with -module libs

okay, forget about that, I did resolve a few other problems during libtool sequencing, and finally the "ld" does not accept the module.dll as the cross-gcc's ld does also add a "lib" at each "-l$name".. and can not find the module.dll Now I have to rethink a few bits, like renaming the build-lib

Re: dll cross-compile, .libs/impgen is a win-exe, not a linux-binary

What is HOST_CC ? It has no default, and cross-gcc is the wrong cc. Did now try with HOST_CC=/usr/bin/cc to get a working impgen. Did not work either - look for the ".libs/.libs" part in the output which is clearly wrong. There is no check, if the output is empty - it would atleast contain the "

dll compile, can not resolve with -module libs

As everyone knows, compiling a win-dll requires all references to be resolved at link-time, and therefore libtool needs to know all lib-files by their name in the link-stage. A project of mine contains a few module-dll that are installed into $pgklibdir and "dlopen"-ed. Now there is a module2-dl

Re: ld --auto-import for cygwin and libtool

On Jun 11, 2001, "Robert Collins" <[EMAIL PROTECTED]> wrote: > I think the shlib_overrides_runpath means the LDPATH on unix systems, > and PATH on win32 systems, overriding the -rpath compiled in path. In > which case it should be yes on win32, because AFAIK the compiled in path > is ignored :].