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,
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
wrapper
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.
I'm going out of town for
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 town for a few
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:
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 to
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...
Yes,
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
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:
*** Warning: linker path
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-devel
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 realize
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
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 set
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-devel
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
# Method to
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
18 matches
Mail list logo
