Re: MinGW link against an MS Windows import library

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 ext

Re: MinGW link against an MS Windows import library

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 make

Re: GNU Libtool 1.5.2 released

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 pre

Re: Version numbering

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 th

Re: libtool pre-1.5b tests fail on 9 debian arches

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, the

Re: should libtool check for the correct version of find?

Matthew Arnison wrote: Hi libtool developers and users, libtool appears to depend on Unix find. Under Cygwin, an incorrect path can cause the Windows FIND to be used instead. To the untrained eye, (that is, me two days ago) it's not obvious from the output of configure and libtool that this has

Re: Creating lock file for compilers that don't support -c -o

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 race-co

Re: Building static-only or shared-only libraries on a per targetbasis

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 ti

Re: Building static-only or shared-only libraries on a per targetbasis

But what if I want both? Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: Cyclic dependencies

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

Re: 1.5 automatically generating C++, F77 tags

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. ___

Re: libtool and cl

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 pas

Re: [Mingw-users] Re: Solving the "relink exe's" libtool problem[take 3]

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 el

Re: Wrong path at linking

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] http://mail.gnu.o

Re: How to specify a version script?

Josh Huber wrote: "Howard Chu" <[EMAIL PROTECTED]> writes: Yes, this is a nagging problem, the Cyrus folks seem to be mired in a swamp of out-of-date build tools and for whatever reasons are constrained not to update themselves. I've raised this issue with them before. So far we've been able to

Re: Cygwin List O' Issues...[make install DESTDIR=]

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. Becau

EXEEXT and -link

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 modified

Re: Library creation 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

Re: Deprecate AC_LIBTOOL_WIN32_DLL?

Robert Collins wrote: On Sat, 2002-10-26 at 08:24, Bob Friesenhahn wrote: On Sat, 26 Oct 2002, Kevin Ryde wrote: Bob Friesenhahn <[EMAIL PROTECTED]> writes: Comments? Is it still true that global variables exported from a dll must have a dllimport directive for applications? AC_LIBTOOL_W

Re: Deprecate AC_LIBTOOL_WIN32_DLL?

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, give

Re: [Mingw-msys] Proposed libtool patch for MinGW

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. >

Re: [Mingw-msys] Re: MinGW libtool DLL failure

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

Re: [Mingw-msys] Re: Proposed libtool patch for MinGW

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

Re: [Mingw-msys] Re: MinGW libtool DLL failure

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 wa

Re: [Mingw-msys] Re: MinGW libtool DLL failure

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

Re: [Mingw-msys] Re: MinGW libtool DLL failure

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? > >

Re: [Mingw-msys] Re: MinGW libtool DLL failure

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 charac

Re: [Mingw-msys] Re: MinGW libtool DLL failure

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

Re: MinGW libtool DLL failure

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

Re: MinGW libtool DLL failure

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

Re: MinGW libtool DLL failure

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

Re: MinGW libtool DLL failure

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.

Re: MinGW libtool DLL failure

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

Re: Libtool 1.4.3

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

Re: Libtool 1.4.3

Lars Hecking wrote: > Bob Friesenhahn writes: > >>On 8 Oct 2002, Akim Demaille wrote: >> >>>There is one big question which must be answered first: will it have >>>to be Autoconf 2.13 compatible? >>> >>>I *strongly* suggest that it must not. It should AC_PREREQ 2.54 >>>immediately. Then, I'm fi

Re: Libtool 1.4.3

Bob Friesenhahn wrote: > On 8 Oct 2002, Akim Demaille wrote: > >>There is one big question which must be answered first: will it have >>to be Autoconf 2.13 compatible? >> >>I *strongly* suggest that it must not. It should AC_PREREQ 2.54 >>immediately. Then, I'm fine with checking the M4 code an

Re: Shared C++ libraries on AIX

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 ac

Re: [Mingw-users] libtool and Mingw DLLs - bindir/libdir solution - requesting comments

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. > > An

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

Ok, so what do we need to do to get this patch committed? Earnie. Elizabeth Barham wrote: > > 2002-09-29 Elizabeth Barham <[EMAIL PROTECTED]> > > * libtool.m4 (AC_LIBTOOL_SETUP): GCC now checks -shared to > create a dll for Windows targets. > > Thanks, Elizabeth > >

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

Sorry, Elizabeth, this still isn't correct. Elizabeth Barham wrote: > > 2002-09-29 Elizabeth Barham <[EMAIL PROTECTED]> OK. > * modified _LT_AC_LOCK so that, if AC_LIBTOOL_WIN32_DLL is Wrong. More like: * libtool.m4 (AC_LIBTOOL_SETUP): GCC now uses -shared to create a dll

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

Elizabeth Barham wrote: > > Here goes again: > > Index: libtool.m4 > === > RCS file: /cvsroot/libtool/libtool/libtool.m4,v > retrieving revision 1.264 > diff -u -3 -p -r1.264 libtool.m4 > --- libtool.m4 10 Sep 2002 13:50:06 -

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

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 revi

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

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 af

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

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. > > T

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

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

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

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 conte

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

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.

Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

Elizabeth Barham wrote: > > Hi, > > A while back, Bob mentioned running into some trouble linking a dll > with the stub lib*.a libraries: > > > > and has contributed some patches to libtool (whether in regards to > this I do not kno

Re: [Mingw-users] Re: libbfd, libtool & Win32

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 compil

Re: [Mingw-users] Re: libbfd, libtool & Win32

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 ever

Re: "Re: libbfd, libtool & Win32" and "Re: Building a MinGW GLib etc..."

Max Bowsher wrote: > > Earnie Boyd wrote: > [ stuff about impgen ] > > So, why isn't dlltool being used? BTW, dllwrap is deprecated. > > > > Current versions of GCC require -shared in the link step to produce the > > dll. The -dll -mdll switches are de

Re: Intel icc and shared libs

[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 ve

Re: [Mingw-users] Re: libbfd, libtool & Win32

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

Simple dll and static library creation for MinGW

See attached. This sample is the simplest documented valid form for creating both shared and static libraries with current versions of gcc tools for win32 collectively known as MinGW. Earnie. mingwlibsample.tar.gz Description: GNU Zip compressed data

Re: [Mingw-users] Re: "Re: libbfd, libtool & Win32" and "Re: BuildingaMinGW GLibetc..."

Guido Draheim wrote: > > Earnie Boyd wrote: > > Guido Draheim wrote: > > > >> > >>No, because I did just switch my system, and have to reinstall some > >>rpms - crosscompiler and stuff is some that. Atleast I am still > >>miss

Re: [Mingw-users] Re: "Re: libbfd, libtool & Win32" and "Re: Buildinga MinGW GLibetc..."

Guido Draheim wrote: > > > No, because I did just switch my system, and have to reinstall some > rpms - crosscompiler and stuff is some that. Atleast I am still > missing the crosscompiled zlib stuff that I used to use to > crosscompile the project - before going deeper, here's a quick try > wit

Re: [Mingw-users] Re: "Re: libbfd, libtool & Win32" and "Re: Building a MinGW GLibetc..."

Guido Draheim wrote: > > Max Bowsher wrote: > > 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,

Re: [Mingw-users] Re: "Re: libbfd, libtool & Win32" and "Re: Building a MinGW GLibetc..."

Max Bowsher wrote: > > Guido Draheim wrote: > > (B) final $dlname to ../bin/$dlname - interesting way to do about this > > but probably interfering with autoconfed installpath specs (I for > > one use an ac-macro to make the default of $libdir the same as > > $bindir which has the

Re: Portability of find(1)

Akim Demaille wrote: > > Hi People! > > I'm looking for information on the portability of find(1). Please, > send me everything you know. In particular, I think I'm understanding > that `{}' is portably replaced by the argument only when alone, i.e., > exactly > > find ... {} ... > >

Re: cygwin libtool breakage

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

Re: Forbidden strings

--- 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 va

Re: Forbidden strings

guys, and say nothing about > them. Why not just prefix the reserved autoconf variables with a `_' character? This would be normal for vendor supplied tools and prevents user name space pollution. Cheers, = Earnie Boyd mailto:[EMAIL PROTECTED] --- <http://earniesystems.s