--- Akim Demaille [EMAIL PROTECTED] wrote:
"Alexandre" == Alexandre Oliva [EMAIL PROTECTED] writes:
Alexandre On Nov 6, 2000, Earnie Boyd [EMAIL PROTECTED] wrote:
Why not just prefix the reserved autoconf variables with a `_'
character?
Alexandre autoconf used to use ju
Robert Collins wrote:
I _did_ have autoconf CVS HEAD at one point, I reverted to 2.13 to be in
line with other users, and I haven't upgraded again yet. I don't recall
this problem from back then.. if that helps at all :]
Rob
Hi Robert,
Don't know if you follow the autoconf list but you
Guido Draheim wrote:
Just my point. It's nice that cygwin wants to emulate the unix behaviour
to a degree that even data-symbols are im/exported in the usual manner,
that's different with mingw-software where I do take the burden to make
it ready to run in crippled environment, just to make
[EMAIL PROTECTED] wrote:
== bw == Bill Wendling [EMAIL PROTECTED] writes:
bw # How to pass a linker flag through the compiler. wl=
bw to:
bw # How to pass a linker flag through the compiler. wl=-Wl,
bw That might help things...
On the version of icc that I use,
David Olofson wrote:
However, it's still a very bad idea to compile tools as part of the
application build process. ;-)
Right, if you want to install implib as part of distributable resource
when target == some win32 platform (Cygwin, MinGW, MSVC, etc.) fine, but
don't create it in every
David Olofson wrote:
That brings up another interesting point: If impgen was to be compiled
when installing libtool, wouldn't that result in the same problem? I
mean, impgen should only build when you're installing libtool for a cross
compiler - and then you're in that darn cross compiler
Elizabeth Barham wrote:
Hi,
A while back, Bob mentioned running into some trouble linking a dll
with the stub lib*.a libraries:
http://mail.gnu.org/pipermail/libtool/2002-June/006401.html
and has contributed some patches to libtool (whether in regards to
this I do not know).
Elizabeth Barham wrote:
Earnie Boyd [EMAIL PROTECTED] writes:
Not, totally, but it's being worked upon. I've joined the libtool list
as well in order to help with resolving the issues with mingw32
host/build/target issues. Hopefully, others that have been actively
working
Oscar Fuentes wrote:
Guido Draheim [EMAIL PROTECTED] writes:
'-lm' does not exist on win32,
There is a libm.a on MinGW's lib directory. Seems it is a dummy
library for those *nix builds that uses -lm.
Oh, yes, I forgot about that. Should this be removed?
Here's the contents:
$ nm
Hmm..., if libtool.m4 exists in the package, make sure you replace it
with a copy from the CVS and execute aclocal again.
Earnie.
Elizabeth Barham wrote:
Earnie Boyd [EMAIL PROTECTED] writes:
Not, totally, but it's being worked upon. I've joined the libtool list
as well in order
Elizabeth Barham wrote:
This is just a simple report-in about the errors I mentioned having
yesterday or the day before. The latest CVS libtool did not have any
trouble and made the DLL fine.
I'd also like to mention that the whole libtool seemed to work quicker
than before.
Thank you
Elizabeth Barham wrote:
Earnie Boyd [EMAIL PROTECTED] writes:
Ok, submit a proper patch against the CVS source to [EMAIL PROTECTED] for
proper credit for the fix.
Okay, I am satisfied with this and submit this patch for peer review.
Please, use cvs diff -u3p.
SYNOPSIS:
Adds
Max Bowsher wrote:
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
Ossama Othman wrote:
Hi,
On Mon, Oct 07, 2002 at 07:01:04PM +0200, Martin Frydl wrote:
progname=`$echo $0 | ${SED} 's%^.*/%%'`
The problem is with SED variable, it is not defined anywhere in libtool
script. I think the CVS version is currently unstable.
Did you run aclocal in your
Paolo Bonzini wrote:
Wouldn't it be better to get libtool 1.5 out the door? The resources
required to achieve a releasable product are similar and CVS libtool
already contains most of the fixes that would go into a 1.4.3.
But it also contains more features. Releasing 1.5 should be done
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/Image.o
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.
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 to the .lib
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 link to a
dll
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, but I thought that you
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?
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
Max Bowsher wrote:
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?
I prefer Bob's method.
Earnie.
___
Libtool mailing list
Charles Wilson wrote:
The one remaining niggle is this: you *must* specify -no-undefined, or
libtool won't even attempt to build a DLL.
I agree.
But anyway, -no-undefined is a whole separate issue. As far as
AC_LIBTOOL_WIN32_DLL, from the cygwin perspective it can be killed.
However,
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]
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
Kevin Ryde wrote:
Olaf Weber [EMAIL PROTECTED] writes:
Shouldn't that be ARFLAGS, just as we have CFLAGS not C_FLAGS. That
seems to be the canonical name.
Libtool uses AR_FLAGS currently. Whichever is adopted it'd be nice
for them to be the same.
Then libtool is wrong. Based on the GNU
There's a problem in that libtool directs the binary output to the .libs
directory with a script built to execute the binary. The script does
not and cannot have the .exe extention. So the question is, how to go
about resolving the issue?
The issue is the fact that the make target is
Charles Wilson wrote:
Also, since this is probably an 'is_absolute' check, it should really be
[\\/]* | ?:[\\/]* ) (cfr the File System Conventions chapter in
the autoconf manual's portability section).
This part won't work. It's possible we need a separate case for A:style
paths.
Szekely Izabella wrote:
Hy!
I use libtool 1.4.2, automake 1.4-p5, autoconf 2.13 on RedHat linux 7.3.
You should at least try it with newest released versions of these softwares.
Earnie.
___
Libtool mailing list
[EMAIL PROTECTED]
This patch passes my test. What do we need to do to get this accepted
into libtool cvs HEAD?
Earnie.
Charles Wilson wrote:
Okay, this version
1) puts lt-foo.c into .libs
2) libtool --mode=clean does the right thing --- cleans up foo,
foo.exe, .libs/foo.exe, .libs/lt-foo.c, plus whatever
Charles Wilson wrote:
With respect to Bob, Gary's decision to remove it was correct at the
time. Unmaintained, untested code should NOT simply be carried along
because it might be needed later. It would have made development on
actual used and tested platforms [e.g. cygwin/mingw] for the past
Albert Chin wrote:
I don't have a problem requiring AC_PROG_CXX, AC_PROG_F77, or
AM_PROG_GCJ before AC_PROG_LIBTOOL. Anyone see this as a problem?
Reading through the thread, AC_REQUIRE kept coming to my mind, so no I
don't see a problem.
Earnie.
Thomas Maier wrote:
Sigh. It's not a perfect world. Quoting myself: I guess as a
linux-only user I am kind of ignorant or, well, at least a newbie to
portability things. After having spent days reading about that stuff I
already suspected linux does things in a rather modern way. But I
didn't
But what if I want both?
Earnie.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Ralph Schleicher wrote:
Earnie Boyd [EMAIL PROTECTED] writes:
But what if I want both?
Do nothing special, its the default libtool behavior.
If you want to ensure that both kinds of libraries are
built for a package, check for enable_shared=yes and
enable_static=yes at configure time.
My
Paul Jarc wrote:
Bob Friesenhahn [EMAIL PROTECTED] wrote:
Creating a symbolic link requires testing for an existing file, and
then (if the file does not exist) creating a new file, and a
directory entry to reference it. This requires multiple network
transactions with an opportunity for
Oh, to the ode of creating new worms...
Robert Millan wrote:
On Sat, Sep 27, 2003 at 07:26:20PM +0100, Scott James Remnant wrote:
Updating to any later version of Libtool is the same amount of work,
whether it be the Debian-patched version or not. Most of the time, when
build failures occur,
Scott James Remnant wrote:
Not sure whether it's a concern, but generally most packaging systems
(RPM springs to mind) do not allow a '-' in the package's upstream
version.
It's only a concern to the RPM users and maintainers.
If it's a CVS snapshot for the next version increment just timestamp
Bob Friesenhahn wrote:
Autoconf now performs two levels of header tests. One level is to
check that the header file exists, while the other is to ensure that
it can be entirely preprocessed correctly. Probably /lib/cpp is used
because it is more work to figure out how to use the compiler as a
Tim Van Holder wrote:
Bill Jones wrote:
So the basic question is how do I specify a static import library
with a *.lib extension to be used by libtool for resolving the
symbols provided by a non-libtool DLL when building a dependent DLL
with libtool?
The trivial solution is of course to
Bob Friesenhahn wrote:
On Wed, 14 Apr 2004, Bill Jones wrote:
I have considered this but do not see it as a practical solution. I do
not think that it should be the responsibility of every developer to
make a copy of a file simply because the extension is not what libtool
likes. The .lib
42 matches
Mail list logo
