-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dave Korn wrote:
> Uh, no, not sure what you're referring to; got a reference?
http://cygwin.com/ml/cygwin/2008-04/msg00378.html
> Another thought occurs: does that work for cross-compilation?
You can't use /usr/bin/libtool for cross-compilati
Yaakov (Cygwin Ports) wrote on 13 October 2008 04:52:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Dave Korn wrote:
>> Yep, you've got it. The problem is that OBJDUMP is not set to
>> anything, and so the regexes all fail pretty hard. And the reason that
>> OBJDUMP is not set to an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dave Korn wrote:
> Yep, you've got it. The problem is that OBJDUMP is not set to anything, and
> so the regexes all fail pretty hard. And the reason that OBJDUMP is not set
> to anything is due to this very common idiom in GNU projects that exerc
e magic test)
>>
>> Is it the /usr/lib/w32api location that libtool is having a hard time
>> with, the .a extension, or something else?
>
> No, it's not a file type or identification problem; libtool can't find
> libwinmm.a at all.
Yep, that's correct. You eve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Yaakov (Cygwin Ports) wrote:
| This package had AM_GNU_GETTEXT in configure.ac without any arguments
| nor AM_GNU_GETTEXT_VERSION. autoreconf decided "not using Gettext"[1]
| and didn't install config.rpath[2]. But AC_LIB_RPATH (from the included
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
| Looks like a gettext bug to me. Might be fixed in 0.16+, but please
| report upstream.
I'll admit I'm not that fluent in gettext internals. Obviously both
macros are supposed to be present; is having only one just old
behav
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
| Well, that's not enough information at all. The c++ tests all pass, so
| I'm going to need a testcase or at least the actual project you're
| building that gives this error.
.cygport attached, as well as the diff between the
Yaakov (Cygwin Ports) wrote:
Here's yet another interesting case with libtool-2.2:
"interesting", as in "may you live in interesting times"?
/bin/sh ../../libtool --tag=CXX --mode=link g++ -O2 -pipe-o
libfoo-1.2.la -rpath /usr/lib -no-undefined sources.lo
libtool: link: rm -fr .libs/lib
Yaakov (Cygwin Ports) wrote:
* libtool should catch if the lt-foo.c compile fails;
Yes. I haven't tracked this one down yet.
I think I have also found a separate case of breakage when the CXX tag
is enabled, in which case LTCC is mysteriously undefined. The results:
./libtool: line 7737: -O
Charles Wilson wrote:
Yaakov (Cygwin Ports) wrote:
./.libs/lt-foo.c:263: warning: string length `4368' is greater than the
length `4095' ISO C99 compilers are required to support
This one can be fixed by splitting the string into two pieces. I'm
working on a patch for that.
./.libs/lt-foo.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chuck,
Here's yet another interesting case with libtool-2.2:
/bin/sh ../../libtool --tag=CXX --mode=link g++ -O2 -pipe-o
libfoo-1.2.la -rpath /usr/lib -no-undefined sources.lo
libtool: link: rm -fr .libs/libfoo-1.2.dll.a .libs/libfoo-1.2.la
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
| What's puzzling is there is no *error* message from the compiler -- just
| warnings.
|
|> strip: './foo.exe': No such file
|
| But obviously something went wrong.
|
| I wonder of the string length warning is from the pre-proc
Yaakov (Cygwin Ports) wrote:
I'm not sure what's triggering this, but *sometimes* I'm getting more
than that:
./.libs/lt-foo.c:263: warning: string length `4368' is greater than the
length `4095' ISO C99 compilers are required to support
./.libs/lt-foo.c: In function `main':
./.libs/lt-foo.c:288
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
| That was fixed in libtool CVS after 2.2.2 was released:
| http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00019.html
| but this release is 'stock' libtool-2.2.2 with only your patches.
I'm
Charles Wilson wrote:
> way to get ld to print its search path (which is why Brian grep'ed the
> binary) like gcc's -print-search-dirs. So libtool has no mechanism to
I grepped the default linker script which is a plain text file. This
can be done programmatically by adding -Wl,-verbose to a tes
7;:
./.libs/lt-foo.c:288: warning: implicit declaration of function `_setmode'
./.libs/lt-foo.c:288: warning: nested extern declaration of `_setmode'
That was fixed in libtool CVS after 2.2.2 was released:
http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00019.html
but t
Yaakov (Cygwin Ports) wrote:
Charles Wilson wrote:
| I think that libtool hasn't been told that LDFLAGS should include
| -L/usr/lib/w32api. I think this is something that should be passed on
| the invocation line in your makefile -- maybe AM_LDFLAGS needs to be set?
As I'm sure you're aware, /u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
| Changes sine libtool2.2-2.2.2-1
| =
I'm also seeing these warnings (where 'foo' is the executable being
linked against a yet-uninstalled libtool library):
./.libs/lt-foo.c: In function `main'
Charles Wilson wrote:
> I think that libtool hasn't been told that LDFLAGS should include
> -L/usr/lib/w32api. I think this is something that should be passed on
> the invocation line in your makefile -- maybe AM_LDFLAGS needs to be set?
But the linker searches this location by default:
$ grep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
| I think that libtool hasn't been told that LDFLAGS should include
| -L/usr/lib/w32api. I think this is something that should be passed on
| the invocation line in your makefile -- maybe AM_LDFLAGS needs to be set?
As I'm su
l.
FWIW:
$ ./func_win32_libid.sh /usr/lib/w32api/libwinmm.a
x86 archive import
So that's ok. (func_win32_libid.sh is just func_win32_libid() from
libtool-2.2.2-2, with the OBJDUMP/NM/etc variables set.
--
Chuck
#!/bin/bash
ECHO=echo
OBJDUMP=objdump
EGREP="grep -E&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
| Changes sine libtool2.2-2.2.2-1
| =
| o changed base package name from 'libtool2.2' to 'libtool'
| o Added patches from Yaakov Selkowitz
| http://cygwin.com/ml/cygwin/2008-04/msg00378.html
D
GNU libtool is a generic library support script. Libtool hides the
complexity of using shared libraries behind a consistent, portable
interface.
This update represents a name change from the previous 'libtool2.2'
package, to the new 'libtool' package (the embedded version number '2.2'
has been
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
| I believe this was an attempt at optimization: avoid testing for
| specific tools need only on one platform, unless libtool has been told
| that it is ON that platform. Oddly, you'd think that libtool would
| figure that out
Yaakov (Cygwin Ports) wrote:
One more patch will be required, namely, to define OBJDUMP where
necessary. I've rolled these two patches together, as attached.
Explanation:
The AC_LIBTOOL_WIN32_DLL macro was supposed to be used in packages which
built on Win32 platforms, in order to create DLLs.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
| Yaakov (Cygwin Ports) wrote:
|> AU_DEFUN([AC_PROG_LIBTOOL],
|> [LT_INIT
|> LT_OUTPUT
|> AC_DIAGNOSE([obsolete],
|> [$0: Remove this warning and the call to LT_OUTPUT if you do not need
|> libtool to exist before AC_OUTPUT.])
Chuck,
Well, I tried libtool 2.2.2 on a 1.5 package with autoreconf.
Unfortunately it wouldn't build any shared libraries:
/bin/sh ../libtool --tag=CC --mode=link gcc -O2 -pipe-o
libgdasql-3.0.la -rpath /usr/lib -version-info 3:0:0 -no-undefined
parser.lo lexer.lo sql_parser.lo m
Yaakov (Cygwin Ports) wrote:
Charles Wilson wrote:
| I'm not so sure. I still think that calling LT_OUTPUT immediately after
| LT_INIT is not exactly equivalent to 1.5 behavior.
I think it is equivalent, seeing from a typical configure run with
libtool 1.5:
Looking at some of the other compatib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
| I'm not so sure. I still think that calling LT_OUTPUT immediately after
| LT_INIT is not exactly equivalent to 1.5 behavior. I think that is too
| early...but I don't know how to force a non-local insertion of
| LT_OUTPUT, an
Yaakov (Cygwin Ports) wrote:
Charles Wilson wrote:
I'm now looking at 2.2, what I mean is instead of (in libtool.m4):
AU_ALIAS([AC_PROG_LIBTOOL], [LT_INIT])
AU_ALIAS([AM_PROG_LIBTOOL], [LT_INIT])
Do something like the following:
AU_DEFUN([AC_PROG_LIBTOOL], [
LT_INIT
LT_OUTPUT
])
AU_DEFUN([AM_P
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
| True. But that is NOT required. libtool-emit-time is simply a new
| (possible backwards-incompatible) behavior change of the new libtool --
| but one that hopefully impacts few clients.
I guess I'll be finding out exactly ho
Yaakov (Cygwin Ports) wrote:
Charles Wilson wrote:
| That should be taken up with the libtool maintainers. However, it has
[snip]
If I need to add LT_OUTPUT already, then I might as well switch entirely
to the LT_* macros.
True. But that is NOT required. libtool-emit-time is simply a new
(p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
| That should be taken up with the libtool maintainers. However, it has
| been their position, even in the libtool-1.4 and -1.5 days, that relying
| on that behavior was not recommended. Therefore they do not support it
| "di
Yaakov (Cygwin Ports) wrote:
*) Most packages still use a 1.5 libtool, if not older. Is LT_OUTPUT
the default if the old-style AC_PROG_LIBTOOL macro is called?
No, it is not.
If it's
not, it should be, as I know of a number of packages which rely on the
libtool script during configure.
Th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chuck,
I have yet to try libtool 2.2, but I'm sure that you have thoroughly
tested it. Could you clarify a few things:
*) Most packages still use a 1.5 libtool, if not older. Is LT_OUTPUT
the default if the old-style AC_PROG_LIBTOOL macro is cal
Brian Dessent wrote:
Angelo Graziosi wrote:
and if cygport depend on libtool1.5, how can the user who needs
libtool2.2 install it without uninstalling libtool1.5+cygport+...?
I think cygport should remove its requires: libtoolx.y from its
setup.hint. It currently lists that because the defa
Angelo Graziosi wrote:
> and if cygport depend on libtool1.5, how can the user who needs
> libtool2.2 install it without uninstalling libtool1.5+cygport+...?
They would have to manually override the warning of setup in order to
install libtool2.2+cygport.
> If one install libtool2.2 without re
Brian Dessent wrote:
This shouldn't be too big of a problem as the libtool packages are
> only needed if you relibtoolize something -- which you normally do not
> when building from a tarball, only from a VCS checkout. Though
> building any cygport-ized package seems to force the issue since it
Angelo Graziosi wrote:
> If this is the case, perhaps, there is some problem in setup.ini.
>
> cygport requires libtool1.5 and libguile17 requires libltdl3.
>
> So it looks that the set libtool1.5+libltdl3 cannot be removed in favor
> of libtool2.2+libltdl7 (if one needs cygport, libguile17+ dep
Brian Dessent wrote:
> Per the release announcement, it is incompatible with the libtool1.5
> package, which means you have to manually deselect all other libtool
> packages if you select libtool2.2. You can only have one of the two
> at any time installed
If this is the case, perhaps, there is
Bobby McNulty wrote:
> Last night, I updated my Cygwin installation and received libtool 2.2.2
Seeing as how libtool2.2 is not listed in any 'requires:' line you must
have manually selected it in order for it to be installed. Per the
release announcement, it is incompatible with t
Last night, I updated my Cygwin installation and received libtool 2.2.2
This afternoon. I tried building subversion 1.5 branch.
I got to the first library, and libtool said it could not build a shared
library.
That only static libraries could be built.
My exact configure went like this
42 matches
Mail list logo
