Bob Rossi wrote:
I've recently converted pcre's (http://www.pcre.org/) build
system to use the autotools.
The previous stable version of libtool, pcre-7.0, used to create dll's
on mingw. It would create
$ ls .libs/*.dll
I sent the below to [EMAIL PROTECTED], but it's been a month with no
response, so now I'm trying [EMAIL PROTECTED] instead:
Max Bowsher wrote:
Looking at the documentation about how to update -version-info:
1. Start with version information of `0:0:0' for each libtool library.
2
Looking at the documentation about how to update -version-info:
1. Start with version information of `0:0:0' for each libtool library.
2. Update the version information only immediately before a public
release of your software. More frequent updates are unnecessary,
and only
Ralf Wildenhues wrote:
for your projects. For best results on Cygwin, you should probably
configure (with libtool HEAD) like
CONFIG_SHELL=/bin/ash lt_ECHO='printf %s' /bin/ash configure [...]
(replace /bin/ash with the path to Cygwin's Almquist shell clone).
That path would be /bin/sh, so it's
What is the estimated timeline towards 2.0?
Max.
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
[EMAIL PROTECTED] wrote:
Hi Max,
Sorry for the mistake but in fact I invoke libtoolize -f -c' and
'automake-1.7 -a -c '!
Anyway, I get a new ltmain.sh, the one is stored in my libtool (1.4.3)
directory.
So, either ltmain.sh is bad in libtool-1.4.3 (I don't think so) or the
source
file
[EMAIL PROTECTED] wrote:
Ok, Ok Max.
Now I remember also that I had to do 'aclocal-1.7 -I ./m4 ...' and
according
to the libiconv developper, he use slightly modified libtool1.5 files.
That's
the reason why I get a serial 47.
So, I suppose I have to update aclocal and automake to maybe 1.8
J. Ali Harlow wrote:
On 2003.09.04 09:45 Alexander Kogan wrote:
Hi!
I build DLL with mingw/automake/autoconf/libtool. But this dll depends
on external static lib, and libtool doesn't produce dll, but say that
it will be built when I compile program with this library. But I use
this dll in
Gerrit P. Haase wrote:
Hallo Alex,
I'm using libtool 1.4.2 on a redhat 8.0 machine and when do a make
install in my project libtool relinks all my libs and binaries.
How can I disable this? I never run my binaries from the build area,
only from the installed prefix.
Linking a large C++
Bob Friesenhahn wrote:
On Fri, 28 Mar 2003, Robert Boehne wrote:
Braden,
For libltdl to work, you'd have to have Windows
declspec(__dllimport) and declspec(__dllexport) applied
properly, which isn't currently done. As far as libname.lib
It used to be supported by libltdl, but when GCC
Hi - Subject says it all, really.
The -someoption isn't present in the untagged CC= in the generated libtool.
(In is in LTCC=, incidentally.)
All works ok with a tagged (e.g. CXX) configuration.
I've been working around this with this adhoc patch - mostly created by
educated guessing than a true
Earnie Boyd wrote:
Bob Friesenhahn wrote:
On Mon, 14 Oct 2002, Max Bowsher wrote:
I floated an idea on how to get around that: Adjust the libtool
invocation command (as determined in libtool.m4) to be libtool
--bindir=$(bindir) (or perhaps with appropriate quoting). The idea
being
Guido Draheim wrote:
Would bindir be an environment variable if libtool is being executed
from make? If not, setting a variable in the libtool.m4 that
configure sets works. I prefer that over a switch, with a default
value for the variable of ../bin. If bindir is passed to libtool
through
Bob Friesenhahn wrote:
On Tue, 15 Oct 2002, Max Bowsher wrote:
So we conditionalize all this so it only activates on Windows.
There is a fundamental flaw with this logic. Sorry to dissapoint you,
but most open source software using libtool does not originate from
the Windows environment
Earnie Boyd wrote:
The Makefile sets
LIBTOOL := bindir=$(bindir) $(SHELL) $(top_builddir)/libtool
Then:
Test for the existance of bindir in the libtool script, if it doesn't
exist set it to ../bin if it does exist the Makefile has passed it to
libtool via an environment variable.
This
Bob Friesenhahn wrote:
On Tue, 15 Oct 2002, Max Bowsher wrote:
Earnie Boyd wrote:
The Makefile sets
LIBTOOL := bindir=$(bindir) $(SHELL) $(top_builddir)/libtool
Then:
Test for the existance of bindir in the libtool script, if it
doesn't exist set it to ../bin if it does exist
Bob Friesenhahn wrote:
The attached patch to FSF CVS libtool is intended to make libtool
(mostly) behave as it does for Cygwin when executed with MinGW. It
consists of contributions from Elizabeth Barham, and my own efforts.
The DLLs are installed to $(libdir)/../bin as they currently are
Bob Friesenhahn wrote:
On Tue, 15 Oct 2002, Bob Friesenhahn wrote:
Would this part from Automake-generated Makefiles have any impact on
the proposal?
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
Bob Friesenhahn wrote:
The MinGW patch uses libbase-number.dll for DLL naming,
I thought the consensus was base-number.dll (no lib)? Or am I
remembering wrongly?
Max.
___
Libtool mailing list
[EMAIL PROTECTED]
Bob Friesenhahn wrote:
On Mon, 14 Oct 2002, Earnie Boyd wrote:
Well, shouldn't both use $(bindir) to install the dll into?
What would be nice except that I don't believe libtool is provided
with this information at run-time. It acts like a traditional install
program. The Cygwin folks
Elizabeth Barham wrote:
This patch allowed libMagick++ to compile on my machine.
The one thing that concerns me is the name of the import library is
hard-coded ${lib}.a, which is okay in that the import library looks
like qqq.dll.a but Max has something going about putting DLLs with
I am tidying and explaining my patch bit by bit. Here is the second chunk.
A libtool expert needs to check Hunk 2. See my comments below
Once section 1 and 2 have been pronounced OK, they can be commited, as they are
just groundwork for the main chunk of the patch, and can stand alone.
Max.
Guido Draheim wrote:
(A) the sys_lib_search_path spec gets hardcoded to the cygwin path.
no go on mingw cross. $CC -print-search-dirs rules.
I wish I knew why this hack is required on Cygwin
(B) final $dlname to ../bin/$dlname - interesting way to do about this
but probably
Guido Draheim wrote:
How old may a gcc/binutils pair be? My oldest crosscompilers
are gcc 2.95.3 and ld --version reports 2.11.90.8. And for
all I know, these are in fact the oldest versions around,
no one want to go back beyond, I guess.
Is that enough, Max?
Test:
$ echo
Guido Draheim wrote:
I am not that knowing about the actual backgrounds, but to me
it did look as if one can not be sure about the dll.a format,
so that one does not trust it. Unlike cygwin, it is much more
likely that mingw binds with dlls *not* compiled by mingw gcc
but from another
I am tidying and explaining my patch bit by bit. Here is the first chunk,
including the merge of the Cygwin-local changes to libtool (not done by me).
Hunks 1 2 should be fine. Hunk 3 is purely the addition of a comment, which
you may prefer to leave out on the grounds of unnecessary bloat.
26 matches
Mail list logo
