Is your patch against CVS head? Or the release 1.4.2?
Earnie.
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.
>
Bob Friesenhahn wrote:
>
> If libtool was intended to be an extension of Autoconf/Automake, then
> it should certainly have been absorbed into Automake, and not exist as
> a stand-alone utility at all.
>
Do you have examples of libtool use without autoconf and/or automake?
Why does libtool.m4
Max Bowsher wrote:
> 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?
>
I prefer Bob's method.
Earnie.
___
Libtool mailing list
[EMAIL PROTE
Bob Friesenhahn wrote:
>
> The MinGW patch uses lib-.dll for DLL naming, otherwise
> the naming is the same as Cygwin.
Cool. I'm happy.
> This problem has already been anticipated and addressed.
Good to know.
> The patch looks for an existing Cygwin installation and tries to
> overwri
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:
>
A modified version of this patch is now in libtool CVS. The best way
to verify that it works is to try libtool CVS for your packages under
MinGW and Cygwin (one Cygwin part was modified so the implementation
could be shared).
Note that installing DLLs into $(libdir)/../bin seems to be a bit of a
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 current
On Tue, 15 Oct 2002, Charles Wilson wrote:
>
> quick question: what pattern is used to name the dlls, implibs, and
>
> statlibs? (I don't care, I just want to avoid confusion with the cygwin DLL
>
> names). On cygwin, we use:
>
>cyg-.dll (where number= 'current' - 'age')
>lib.dll.a
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 note that Cygwin's patched libtool contains a mo
On Tue, 15 Oct 2002, Nick Humfrey wrote:
> Has anyone considered a method of disabling the "Libraries have been
> installed in:" message when running libtool --finish ?
> I know this can be done using --silent, but that isn't very helpful
> when it is called automatically using exec in the instal
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 note that Cygwin's patched libtool contains a modification to
> postinstall
Hi,
Has anyone considered a method of disabling the "Libraries have been
installed in:" message when running libtool --finish ?
I know this can be done using --silent, but that isn't very helpful
when it is called automatically using exec in the install mode
section.
In my project (OpenQui
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
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 under
Cygwin. Any change to t
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.
> .NOEXPORT:
Here is some
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
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 the Makefile has
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 originate from
> the Windows envir
Earnie Boyd wrote:
> Max Bowsher wrote:
>
>> Earnie Boyd wrote:
>>
>>
>> Unfortunately not - "make install bindir=/alternatelocation".
>>
>>
>>> I prefer that over a switch, with a default
>>> value for the variable of ../bin.
>>
>>
>>
>> I think that a switch is the only way, if we are to deal
On Tue, 15 Oct 2002, Max Bowsher wrote:
>
> >> The idea of supporting a --bindir option is tempting, but then
> >> 'libtool --mode=install' stops looking like a simple install program,
> >> and in fact, the --bindir option would need to be passed for several
> >> different phases of libtool operat
Max Bowsher wrote:
> Earnie Boyd wrote:
>
>
> Unfortunately not - "make install bindir=/alternatelocation".
>
>
>> I prefer that over a switch, with a default
>>value for the variable of ../bin.
>
>
> I think that a switch is the only way, if we are to deal with the case I
> cite above.
>
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
>
>
> 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 the
> envir
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
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 that when used from an
28 matches
Mail list logo
