Chuck wrote:
> New alpha versions of libtool available for test. This is
> very close to
> what libtool-2.0 will be. Please evaluate.
>
> NOTE: cygwin maintainers: do NOT release any updates of your packages
> built using this version of libtool! Be sure to revert back to
> "regular" libtool-de
Peter Ekberg schrieb:
I have one problem with libtool 1.9d, that I suspect is still present
in 1.9f. If I specify -lpthread when linking, libtool searches for a
real file matching -lpthread, like this:
*** Warning: linker path does not have real file for library -lpthread.
*** I have the capability
Reini Urban wrote:
> Peter Ekberg schrieb:
>> I have one problem with libtool 1.9d, that I suspect is still present
>> in 1.9f. If I specify -lpthread when linking, libtool searches for a
>> real file matching -lpthread, like this:
>>
>> *** Warning: linker path does not have real file for library
Peter wrote:
> Reini Urban wrote:
>> Peter Ekberg schrieb:
>>> I have one problem with libtool 1.9d, that I suspect is still present
>>> in 1.9f. If I specify -lpthread when linking, libtool searches for a
[...]
> I have this in the generated libtool script:
> --8<
> # Me
Peter Ekberg schrieb:
Reini Urban wrote:
Peter Ekberg schrieb:
I have one problem with libtool 1.9d, that I suspect is still present
in 1.9f. If I specify -lpthread when linking, libtool searches for a
real file matching -lpthread, like this:
*** Warning: linker path does not have real file for lib
Reini Urban wrote:
> Peter Ekberg schrieb:
>> Reini Urban wrote:
>>> Peter Ekberg schrieb:
>>>
I have one problem with libtool 1.9d, that I suspect is still
present in 1.9f. If I specify -lpthread when linking, libtool
searches for a real file matching -lpthread, like this:
>>
Chuck wrote:
> New alpha versions of libtool available for test. This is
> very close to
> what libtool-2.0 will be. Please evaluate.
>
> NOTE: cygwin maintainers: do NOT release any updates of your packages
> built using this version of libtool! Be sure to revert back to
> "regular" libtool-de
Chuck wrote:
> New alpha versions of libtool available for test. This is
> very close to what libtool-2.0 will be. Please evaluate.
I have further problems in that linking against -ldxguid prevents
a library from being linked as a dll. I only get a static lib,
which is not what I want.
I realiz
Gerrit P. Haase wrote:
libpthread should be in the list of libraries where these tests are
skipped, like it is for libstdc++ or libgcc and others,
Nope. MAYBE it should be skipped, like -lc and -lm are skipped. But
libstdc++ and libgcc are a different kettle of fish.
libtool specifically check
Peter Ekberg wrote:
I have a problem with "make install" of a built executable.
I'm confused.
Background: the only reason you ever need a wrapper script for an
executable in a libtoolized project, is when that executable depends on
an uninstalled shared library. You need the wrapper script to se
Chuck wrote:
> Peter Ekberg wrote:
>> I have a problem with "make install" of a built executable.
> In your case, you have a wrapper script -- but an empty
> noninst_deplibs. One of two things is true:
>
> (1) your exe really truly does not depend on any uninstalled
> libraries. --> so need
Chuck wrote:
> New alpha versions of libtool available for test. This is
> very close to what libtool-2.0 will be. Please evaluate.
"make install-strip" on a shared library strips the import
lib, not the dll which was what I was hoping for.
Not a show-stopper I suppose...
/bin/sh ../libtool -
Peter wrote:
> Chuck wrote:
>> New alpha versions of libtool available for test. This is
>> very close to what libtool-2.0 will be. Please evaluate.
> "make install-strip" on a shared library strips the import
> lib, not the dll which was what I was hoping for.
> Not a show-stopper I suppose..
Gerrit P. Haase wrote:
"make install-strip" on a shared library strips the import
lib, not the dll which was what I was hoping for.
Not a show-stopper I suppose...
Yes, this is a showstopper! Import libraries may be broken after
stripping.
I'm going out of town for a few days, so in the words of
Chuck wrote:
> Gerrit P. Haase wrote:
>>> "make install-strip" on a shared library strips the import
>>> lib, not the dll which was what I was hoping for.
>>> Not a show-stopper I suppose...
>>
>> Yes, this is a showstopper! Import libraries may be broken after
>> stripping.
>
> I'm going out of
Peter Ekberg wrote:
BTW, this is the command that generates the wrapper script
when it shouldn't:
/bin/sh ../libtool --mode=link --tag=CC gcc -g -O2 -D_REENTRANT
-D_THREAD_SAFE -DDEBUG -g -Wall -Wpointer-arith -Wsign-compare
-Wstrict-prototypes -Wswitch -Wmissing-prototypes -Wreturn-type -Wshadow
Chuck wrote:
> It seems like a design decision was made, that IF in a given project
> there are ANY libtool libs, then libtool will "know" about it
> by having
> build_libtool_libs set to "yes". And thus, every executable is
> *assumed* to be linked against those libs, and will therefore have a
>
I wrote:
> Chuck wrote:
>> Gerrit P. Haase wrote:
"make install-strip" on a shared library strips the import
lib, not the dll which was what I was hoping for.
Not a show-stopper I suppose...
>>>
>>> Yes, this is a showstopper! Import libraries may be broken after
>>> stripping.
>>
Chuck wrote:
> New alpha versions of libtool available for test. This is
> very close to what libtool-2.0 will be. Please evaluate.
Ok, I found another problem. You cannot add the flag
-Werror-implicit-function-declaration to CFLAGS as that
kills the build of the wrapper executable. While there,
19 matches
Mail list logo
