Earnie Boyd <[EMAIL PROTECTED]> wrote in
news:3DAC41A9.3070503@;yahoo.com:
> 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 y
On Mon, 21 Oct 2002, Soren A wrote:
> >
> > Do you have examples of libtool use without autoconf and/or automake?
> > Why does libtool.m4 get installed into share/aclocal/? AFAIK, libtool
> > without autoconf/automake doesn't exist.
>
> Echo. I don't dispute that Bob might be correct but TTBOMK th
Soren A <[EMAIL PROTECTED]> writes:
> Echo. I don't dispute that Bob might be correct but TTBOMK this is not
> _common_ knowledge. After extensively messing around with building a
> libtool from GNU cvs within the last 3 weeks, I can say that I see no
> means by which libtool can readily be used a
On Fri, 18 Oct 2002, Albert Chin wrote:
> On Tue, Oct 15, 2002 at 10:43:08AM -0500, Bob Friesenhahn wrote:
> > 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
On Tue, Oct 15, 2002 at 10:43:08AM -0500, Bob Friesenhahn wrote:
> 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 w
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
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
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
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
> autoconf-based makefile (
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
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 are using the ../bin trick to
Well, shouldn't both use $(bindir) to install the dll into?
Earnie.
Bob Friesenhahn wrote:
> What directory should MinGW DLLs be installed in? Cygwin installs
> using the offset ../bin from the directory where the .dll.a file is
> installed. Should libtool behave the same way under MinGW?
>
>
What directory should MinGW DLLs be installed in? Cygwin installs
using the offset ../bin from the directory where the .dll.a file is
installed. Should libtool behave the same way under MinGW?
This seems to make sense as long as "Unixish" behavior is what is
expected by MinGW users. However, t
On Mon, 14 Oct 2002, Robert Boehne wrote:
> It is true that the checking takes some time, ~three seconds on
> a newer Sun workstation (with large limit), but it isn't clear
> to me why it would take even longer under MinGW.
Unfortunately MinGW must run under an inferior OS, particularly
Window
All,
The max_cmd_len variable is used to determine how long a command
can be executed. When Libtool generates a link command that is
longer than this, it breaks the command into successive "ld -r"
invocations that are just short enough to be executed. There are
other parts of the commands that
Tor Lillqvist <[EMAIL PROTECTED]> writes:
>
> I have experienced that the 8192 (umm, don't remember exactly, some
> pretty low limit anyhow) wasn't enough for GTK+, and libtool started
> to use some workaround, which then failed in a mysterious
> way.
In GMP we had a problem with the "ar cru" use
Earnie Boyd writes:
> I've seen some looong command lines, not that I've stopped to count
> the characters. The 8192 may not be enough for some packages.
I have experienced that the 8192 (umm, don't remember exactly, some
pretty low limit anyhow) wasn't enough for GTK+, and libtool starte
Elizabeth,
Here is another MinGW-related problem to fix. I do not know if this
is specific to C++ DLLs, or if it happens for all cases where the
library depends on an uninstalled libtool library. I suspect the
latter since I recall also seeing the problem when building libwmf.
Note that in this
Earnie Boyd <[EMAIL PROTECTED]> writes:
> I've seen some looong command lines, not that I've stopped to
> count the characters. The 8192 may not be enough for some packages.
> Is there a mehtod to use that doesn't check the command line length
> or is the point of the limit to break the comma
On Sat, 12 Oct 2002, Earnie Boyd wrote:
> the characters. The 8192 may not be enough for some packages. Is there
> a mehtod to use that doesn't check the command line length or is the
> point of the limit to break the command line into parts?
I believe that the limit is there to break the comman
Elizabeth Barham wrote:
Earnie Boyd <[EMAIL PROTECTED]> writes:
I'm fine with it and will support the change [of the maximum command
line length] to a constant. Should that constant be adjusted based
on w9x vs NT?
I would not think so; rather, it seems to me that a 8192 character
command li
Earnie Boyd <[EMAIL PROTECTED]> writes:
> I'm fine with it and will support the change [of the maximum command
> line length] to a constant. Should that constant be adjusted based
> on w9x vs NT?
I would not think so; rather, it seems to me that a 8192 character
command line maximum will work fo
Your patch works. Please submit a formal version of this patch (with
changelog) and I will apply it.
Bob
On 11 Oct 2002, Elizabeth Barham wrote:
> Bob, all,
>
>This patch allowed libMagick++ to compile on my machine.
>
>The one thing that concerns me is the name of the import library is
Elizabeth Barham wrote:
What is the MSYS-team's view on this?
I'm fine with it and will support the change to a constant. Should that
constant be adjusted based on w9x vs NT?
Earnie.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.or
"Max Bowsher" <[EMAIL PROTECTED]> writes:
> Don't worry about me! I think we are working towards broadly similar goals -
> it shouldn't be much effort for me to merge the changes you are making into
> my stuff.
What I'm wondering is of there is a better variable to use with the
import library, as
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
On 11 Oct 2002, Elizabeth Barham wrote:
>This patch allowed libMagick++ to compile on my machine.
Great. I'll give it a try tomorrow.
>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.dl
Bob, all,
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
the executables and
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> The exact same error message is reported without -shared.
>From what I can tell, during configure, there is a check for any
object files that are included in a C++ link. This object file is then
later used to build the shared archive.
If you look at
Elizabeth Barham wrote:
>yes,mingw*)
> -library_names_spec='${libname}`echo ${release} | sed -e
>'s/[[.]]/-/g'`${versuffix}.dll'
> +soname_spec='$libname.dll'
> +library_names_spec='$libname.dll.a'
don't cut away the "release" spec.
libtool link --release 10.56 -o libfoo.la
This is a new patch in attempts to correct the strange behavior,
but note, IT DOES NOT WORK CORRECTLY YET.
I am posting this because I have a very specific question about the
naming of the library. This patch, as it is, causes configure to
print out:
checking which extension is used for shared l
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> CVS libtool fails to link C++ DLLs under MinGW, but succeeds under
> Cygwin. I have looked at the .la files, and everything appears to be
> in order there, so the problem seems to be during the C++ DLL link
> phase. The MinGW environment is the base
On Thu, 10 Oct 2002, Earnie Boyd wrote:
> Bob Friesenhahn wrote:
> >
> > Cygwin does not have these problems so we have a working example.
>
> As I've stated before, the workings parts are the same between MinGW and
> Cygwin with regard to producing the end result. AFA libtool is
> concerned the
Earnie Boyd wrote:
> Earnie Boyd wrote:
>
>> Bob Friesenhahn wrote:
>>
>>> On Thu, 10 Oct 2002, Boehne, Robert wrote:
>>>
>>>
The only thing that troubles me about the link line Bob posted is
that a .dll is specified in the link, not the corresponding .lib.
I'm not a Windows guru,
Earnie Boyd wrote:
> Bob Friesenhahn wrote:
>
>> On Thu, 10 Oct 2002, Boehne, Robert wrote:
>>
>>
>>> The only thing that troubles me about the link line Bob posted is
>>> that a .dll is specified in the link, not the corresponding .lib.
>>> I'm not a Windows guru, but I thought that you never l
Bob Friesenhahn wrote:
> On Thu, 10 Oct 2002, Boehne, Robert wrote:
>
>
>> The only thing that troubles me about the link line Bob posted is
>>that a .dll is specified in the link, not the corresponding .lib.
>>I'm not a Windows guru, but I thought that you never link to a
>>dll directly, but t
Bob Friesenhahn wrote:
>
> Cygwin does not have these problems so we have a working example.
>
As I've stated before, the workings parts are the same between MinGW and
Cygwin with regard to producing the end result. AFA libtool is
concerned the two are equal.
Earnie.
On Thu, 10 Oct 2002, Boehne, Robert wrote:
> The only thing that troubles me about the link line Bob posted is
> that a .dll is specified in the link, not the corresponding .lib.
> I'm not a Windows guru, but I thought that you never link to a
> dll directly, but to the .lib that is created whe
On Thu, 10 Oct 2002, Earnie Boyd wrote:
> Elizabeth Barham wrote:
> > Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> >
> >
> >>g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o
>.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o
>.libs/Except
>
> With the link line fully qualified with all of the system libraries and
> objects you could just use ld directly. It would be better, IMO, though
> to remove the system libraries from the link command and allow g[cc|++]
> to add the appropriate system libraries so that if some new system
> l
On 9 Oct 2002, Elizabeth Barham wrote:
> What about removing the first object file, the:
>
> c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o
>
> part?
>
> The reason is that the multiple definitions were coming from within
> that particular object file - what happens without it?
Elizabeth Barham wrote:
> Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
>
>>g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o
>.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o
>.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Im
"Bob Friesenhahn" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Earnie,
>
> Using libtool from the head of libtool CVS, and test building
> ImageMagick under MinGW (MSYS environment), I get multiple-defined
> errors when linking the DLL as shown below.
>
> Id
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o
>.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o
>.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o
>.libs/
By the way, notice that this is a C++ DLL which is being linked
against a C DLL also built by libtool. The C DLL did successfully
link using libtool. The C DLL is based in part on a libtool
"convenience library".
To be honest, I believe that there are still some run-time issues with
C++ DLLs un
The exact same error message is reported without -shared.
Bob
On 9 Oct 2002, Elizabeth Barham wrote:
> Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> > Ideas?
> >
> > g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o
>.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> Ideas?
>
> g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o
>.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o
>.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRe
58 matches
Mail list logo
