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 l
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 p
What is the estimated timeline towards 2.0?
Max.
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
[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 mayb
[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
> f
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
>> t
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
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,
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
Akim Demaille <[EMAIL PROTECTED]> wrote:
> Bruce> Bootstrap-Bash could use a frozen version of configure.
> This means freezing at least one copy of Bash. Doable.
What about someone (probably a user of a machine that actually needs it)
writing a shell function inliner?
ltmain.sh could be postpr
Bob Friesenhahn wrote:
> The MinGW patch uses lib-.dll for DLL naming,
I thought the consensus was -.dll (no lib)? Or am I
remembering wrongly?
Max.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Please note that Cygwin's patched libtool contains a modification
to postinstall_cmds, which I suspect is related to ../bin, as it
involves calling basename.
>>
>> Yes, but this may be part of the Cygwin scheme which hasn't yet made
>> it into mainline CVS.
Bob Friesenhahn wrote:
>
Bob Friesenhahn wrote:
> On Tue, 15 Oct 2002, Max Bowsher wrote:
>>> I am posting this patch with the expectation that concerned parties
>>> will inspect it, test it, and send any fixes so that it can be
>>> incorporated in libtool 1.5.
>>
>> Please not
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 excee
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 a
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 li
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.
>
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 orig
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
>
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)&q
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 f
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 wi
I've thought of a way to reliably get bindir from a Makefile.
In libtool.m4, the command line to invoke libtool is defined - we can
add --bindir="$(bindir)" to it, so that libtool knows explictly what the
bindir is, even when overridden at 'make install' time.
Any comments welcome,
Max.
The ba
Earnie Boyd wrote:
> Elizabeth Barham wrote:
> >
> > Earnie Boyd <[EMAIL PROTECTED]> writes:
> >
> > >
> > > The -shared switch is required to build the dll.
> >
> > If anyone is interested in this, libtool made the dll fine without the
> > main function mentioned above by adding -shared after
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.
--
Earnie Boyd wrote:
> Guido Draheim wrote:
> > hmm, perhaps, the LD can now link with dlls directly, and that should
>
> Yes, indeed it can, and will search for it in the LIBRARY_PATH. If it
> can't find libfoo.dll.a or libfoo.a it will look for libfoo.dll when
> -lfoo is given.
Unfortunately, li
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.
Eit
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 co
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 '__declspec
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 in
31 matches
Mail list logo
