Getting started question:

Hi, If I want to test libtool 1.4 (I develop on openBSD & windows 2K (via cygwin) - which may be an odd combination :-]), what's the recommended autoconf version to get? I saw a message recently about libtool CVS not being autoconf CVS ready which is what has prompted my question. Sometime

RE: [ANNOUNCE] libtool-1.3d

> -Original Message- > From: Gary V. Vaughan [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 02, 2001 12:43 PM > To: Libtool > Subject: [ANNOUNCE] libtool-1.3d > > > After 21 months in heavy development, the Libtool Team is > pleased to announce > alpha release 1.3d of GNU libtool. If

Re: to libtool or not: Windows & Unix NSAPI program

Have you tried a make check on libtool on cygwin recently Robert? It may be supported but it don't work :[. Rob - Original Message - From: "Robert Boehne" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, May 02, 2001 5:44 AM Subject: Re: to libtool o

Re: to libtool or not: Windows & Unix NSAPI program

- Original Message - From: "Boehne, Robert" <[EMAIL PROTECTED]> To: "'Robert Collins'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, May 03, 2001 2:30 AM Subject: RE: to libtool or not: Windows &

Re: Windowed Libtools

- Original Message - From: "Bruce Korb" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, May 16, 2001 7:00 AM Subject: Windowed Libtools > > > "Wont be able to develop ... libtool *ON WINDOWS* any more." > > > > So you're agreeing

cygwin libtool breakage

I think I've tracked down why libtool suddenly died. The failures all seem to be shared library related. The below output is from make on the autobook libhello example. The WinMain@16 symbol, from what I've worked out is meant to be transparently created by combining the library sources with lt

Re: cygwin libtool breakage

Tonights the night for me to cause noise.. I just got the output of make check from another cygwin'er, and they only see 6 failures, not the 35 I'm seeing. I'll assume my machine is bust and work from there. Rob - Original Message - From: "Robert Collins&quo

Re: cygwin libtool breakage

Scratch my prior problem: adding AC_LIBTOOL_WIN32_DLL to configure.in (missed that step in the autobook ) worked wonders. however, back to the failing tests. the first failure, demo-make.test fails because ar is called with no object files. Here, pointers would be useful. This test works on at

make install-strip with libtool (CVS HEAD) && automake (CVS HEAD) fails

Is this a bug, or a non-existant feature? symptoms: automake's makefile calls libtool: STRIPPROG='strip' /bin/sh ./libtool --mode=install -s hello.exe /usr/src/hellolib/build/t /usr/local/bin/hello.exe libtool: unrecognized option `-s' Try `libtool --help' for more information. Rob

[PATCH] runtime wrapper touchup on cygwin

The runtime wrapper on cygwin produces lt-foo.exe.exe if libtool is called with a target filename ending with .exe AFAICT this is due to forcing the .exe exeext on cygwin to allow mv to work. This patch trims .exe from the outputname if it is present. Without this, changing a source file, runnin

[PATCH] fix install on cygwin with shared libraries

There is a current problem with automake and libtool on cygwin when shared libraries are enabled. The problem is in two parts. The root cause of the problem is that the wrapper script for relinking binaries linked with .dll's when they are run from the build directory, cannot have a .exe extensio

Re: make install-strip with libtool (CVS HEAD) && automake (CVS HEAD) fails

- Original Message - From: "Tom Tromey" <[EMAIL PROTECTED]> > >>>>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > Robert> Is this a bug, or a non-existant feature? > Robert> symptoms: > > Robert>

RE: cygwin libtool breakage

> -Original Message- > From: Gary V. Vaughan [mailto:[EMAIL PROTECTED]] > > On Saturday 02 June 2001 5:43 pm, Robert Collins wrote: > > however, back to the failing tests. > > > > the first failure, demo-make.test fails because ar is called with no > >

Re: cygwin libtool breakage

- Original Message - From: "Gary V. Vaughan" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, June 04, 2001 11:25 AM Subject: Re: cygwin libtool breakage > On Saturday 02 June 2001 5:43 pm, R

Re: cygwin libtool breakage

- Original Message - From: "Gary V. Vaughan" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 6:51 AM Subject: Re: cygwin libtool br

Re: cygwin libtool breakage

- Original Message - From: "Robert Collins" <[EMAIL PROTECTED]> > > - Original Message - > From: "Gary V. Vaughan" <[EMAIL PROTECTED]> > To: "Robert Collins" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent:

Re: cygwin libtool breakage

- Original Message - From: "Robert Collins" <[EMAIL PROTECTED]> > - Original Message - > From: "Gary V. Vaughan" <[EMAIL PROTECTED]> > > > > On Monday 04 June 2001 2:22 am, Robert Collins wrote: > > > > -Orig

RE: cygwin libtool breakage

> -Original Message- > From: Earnie Boyd [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 05, 2001 10:55 AM > To: Robert Collins > Cc: Gary V. Vaughan; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: cygwin libtool breakage > > > Robert Collins wrote: >

debugging the cygwin issues I'm having

I'm stepping thru the failing tests. A number were automake-HEAD related as I've mentioned already(*see the end for a refresher) The current one I'm beating my head against is demo-make after demo-shared. Problem summary: libtool is having trouble with the .lo files. It's finding nothing in the

demo-shared.test

what's the expected behaviour for configure//automake//libtool when it cannot build a program due to conflicting options Ie: 1) -static is specified on the link line, but libtool was configured with --disable-static 2) --no-undefined is specificed on the link line, but libtool was configured with

dlpreopen bug with cygwin

dlpreopen generates a list of symbols - say extern char _imp__free; extern char nothing; extern char printf; extern char realloc; from the source library - cyghello-2.dll "nothing" here should be extern __declspec(dllimport) char nothing; "_imp__free" shouldn't be present, because the actual s

auto generate -DLIBfoo_COMPILATION for libtool libraries

The attached patch auto defines -DLIBfoo_COMPILATION in the _CFLAGS variable for libtool libraries. This is a proof of concept patch only, it's probably the wrong way to do it, there may be issues with always adding the define even if there are userland defines present. Consider this a request-to

dll installation logic

The current cygwin shared library installation logic seems to be "install path"../bin This fails for things like l3 in depdemo where the install dir is extradir = $(libdir)/extra extra_LTLIBRARIES = libl3.la I'm not sure what we should use as install logic... maybe walk up the install path unt

Re: dll installation logic

- Original Message - From: "edward" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, June 07, 2001 1:22 AM Subject: Re: dll installation logic > make it a module > > cheers, > edward Wha

Paul Sokolovsky's ld --auto-import

Paul's patch to ld to auto-import symbols seems to work well. I'm currently putting it through all the tortuorus combinations I can think of, that libtool would allow users to do. I've had no trouble so far, except a small conflict with the dll base address, that was hard to find but was easy to f

Re: Paul Sokolovsky's ld --auto-import

- Original Message - From: "Gary V. Vaughan" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, June 10, 2001 9:10 PM Subject: Re: Paul Sokolovsky's ld --auto-import > On Sunday 10 June 2001 12:58

Re: ld --auto-imports

- Original Message - From: "Paul Sokolovsky" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, June 11, 2001 3:35 AM Subject: Re: ld --auto-imports > Hello Robert, &g

Re: ld --auto-imports

- Original Message - From: "Christopher Faylor" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, June 11, 2001 6:11 AM Subject: Re: ld --auto-imports > On Sun, Jun 10, 2001 at 08:35:05PM +0300, Paul Sokolovsky wrote: > >RC> Firstly the feedback. I'm using a

mdemo question

Why doesn't foo1 link to libsub.la? -- how is it expected to resolve sub(). Rob ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

ld --auto-import for cygwin and libtool

I may well have broken libtool stuff, and there are things that can be tidied a bit, but this should work for anyone with the modified ld. Also the ld indenting is probably naffed, but it should be good enough for review by anyone interested. I'm not subscribed to binutils, but am to libtool

Re: ld --auto-import for cygwin and libtool

- Original Message - From: "Charles S. Wilson" <[EMAIL PROTECTED]> > > 1) build-relink.test spits out > > "shlibpath_overrides_runpath should be set to yes." > > I'm not sure what that should be for cygwin, so I'm referring the > > question to the libtool list :]. I'm happy to dig furthe

Re: ask for delivering cygwin 1.1.8 with kde 1.1.2

- Original Message - From: "Ralf Habacker" <[EMAIL PROTECTED]> To: "Cygwin-Apps" <[EMAIL PROTECTED]>; "LIBTOOL-Mailinglist" <[EMAIL PROTECTED]> Sent: Wednesday, June 13, 2001 10:01 PM Subject: AW: ask for delivering cygwin 1.1.8 with kde 1.1.2 Ralf Habacker EMail: [EMAIL PROTECTED]

Re: ask for delivering cygwin 1.1.8 with kde 1.1.2

- Original Message - From: "Ralf Habacker" <[EMAIL PROTECTED]> To: "Cygwin" <[EMAIL PROTECTED]> Cc: "Robert Collins" <[EMAIL PROTECTED]> Sent: Wednesday, June 13, 2001 8:48 PM Subject: AW: ask for delivering cygwin 1.1.8 with kde 1.1.2 >

Re: dll compile, can not resolve with -module libs

- Original Message - From: "Guido Draheim" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 20, 2001 3:04 AM Subject: dll compile, can not resolve with -module libs > > As everyone knows, compiling a win-dll requires all references > to be resolved at link-time, and ther

Re: dll installation logic

- Original Message - From: "Alexandre Oliva" <[EMAIL PROTECTED]> > On Jun 8, 2001, Guido Draheim <[EMAIL PROTECTED]> wrote: > > > hmmm, or an autoconf wrapper macro? > > Nope, this wouldn't work for libraries that are not installed in > libdir, but in a subdir thereof. > Whatever it

Re: Odd Error: 'coudn't commit memory for cygwin heap' during configuration of binutils

Interesting! I'd say that this is because cygwin allocates head for the command line, and doesn't have a built-in limit (AFAIK). libtoolers - perhaps the max command line test should stop somewhere before the multi-megabyte point ? Rob - Original Message - From: "Max Bowsher" <[EMAIL P

Re: DLL_EXPORT and MinGW/Cygwin

You may be interested in looking into the auto-import capability that is hopefully going into libtool 1.5. Also, with some automake perl magic the appropriate defines for libraries can be added automagically to the compile line - I chose *library*_DLL_IMPORT and *library*_DLL_EXPORT to allow corr

Re: DLL_EXPORT and MinGW/Cygwin

- Original Message - From: "Jon Leichter" <[EMAIL PROTECTED]> > > You may be interested in looking into the auto-import capability that is > > hopefully going into libtool 1.5. > > Should I be able to see this in the HEAD branch of CVS? I did a quick check > for "auto-import" and didn't fi

Re: DLL_EXPORT and MinGW/Cygwin

I forgot: The auto import libtool patch is awaiting my FSF contribution form - which I receieved on Monday, and as the post office is now open is going in the mail today. Rob ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listi

re: HOST_CC, crossgcc, mingw32, again/summarized - Re: confusionwith host,build,target

I just do not know and I did not take the time to do some > > > communications to get to know the name of someone who > > > could tell me by his profound knowledge of dlls and gnu-ld. > > > > and: > > > > > Know a wizard who is equally wise on all

Re: HOST_CC, crossgcc, mingw32, again/summarized - Re: confusionwith host,build,target

- Original Message - From: "Guido Draheim" <[EMAIL PROTECTED]> > > Guido, can you succintely describe what impgen does - particularly in a > > cross- environment. > > > > short explanation: > impgen.exe is the first part of an implib.exe - it scans a given dll for > exported symbols an

RE: [Fwd: ltmain.in]

> -Original Message- > From: Michael Matz [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 26, 2002 10:12 PM > On a related note. How long do we want to support that cruft > at all? I > mean the pre- and postdeps. Objects and libraries. I'm not > aware of any > current g++ vers

RE: [Fwd: ltmain.in]

> -Original Message- > From: Michael Matz [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 27, 2002 1:05 AM > To: Robert Collins > Cc: [EMAIL PROTECTED]; Bruce Korb; [EMAIL PROTECTED] > Subject: RE: [Fwd: ltmain.in] > > > Hi, > > On Tue,

distcheck with libtool

testoption_SOURCES = tests/testoption.cc testoption_LDADD = libgetopt++.la == configure.in == dnl dnl Configuration input file for GetOpt++ dnl dnl Robert Collins, [EMAIL PROTECTED] dnl dnl $Id: configure.in,v 1.5 2002/03/01 12:14:39 robertc Exp $ dnl dnl dnl AC_INIT(src/GetOption.cc) AC_PREREQ

minor bug in win32 support

When libtool is targeted at i686-pc-mingw32, and configured with --disable-shared, the following message "libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries" is output. It seems to me that with shared libraries disabled, libtool should not produce any out rel

RE: C++ exceptions don't work from Cygwin DLLs?

Danny, I hope you don't object to being copied in... > -Original Message- > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > Sent: Saturday, May 11, 2002 7:49 AM > To: Bob Friesenhahn > Cc: [EMAIL PROTECTED]; Robert Collins > Subject: Re: C++ exceptions don&

RE: C++ exceptions don't work from Cygwin DLLs?

> -Original Message- > From: Danny Smith [mailto:[EMAIL PROTECTED]] > Sent: Saturday, May 11, 2002 12:03 PM > Known problem which will not be solved until the exception > handling mechansim > of libgcc.a lives in a .dllWhat happens is that there are > too copies of the exception

RE: dynamic library link problems

Why not put those functions in a shared library? That's more portable too (not all platforms play nice with backlinking.) Rob > -Original Message- > From: Robert Stone [mailto:[EMAIL PROTECTED]] > Sent: Sunday, May 12, 2002 5:19 PM > To: [EMAIL PROTECTED] > Subject: dynamic library link

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

On Tue, 2002-09-17 at 08:11, Max Bowsher wrote: > Max Bowsher wrote: > > Robert Boehne wrote: > > > Max, > > > > > > I took a look at the patch, and I don't have any objections > > > to it being checked in to Libtool. Can I get some comment > > > from the mingwin people before I take the leap and

Re: Deprecate AC_LIBTOOL_WIN32_DLL?

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_

Re: Deprecate AC_LIBTOOL_WIN32_DLL?

On Sun, 2002-10-27 at 06:00, Bob Friesenhahn wrote: > This is good info, however, the more pressing matter is that I don't > see any evidence that AC_LIBTOOL_WIN32_DLL currently supports a > flag which determines if DLLs will built. > > There is the variable lt_cv_cc_dll_switch but this is not use

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

On Tue, 2003-08-26 at 03:58, Bob Friesenhahn wrote: > On Mon, 25 Aug 2003, Albert Chin wrote: > Maybe there is some other hard-link which can be used instead? Renames, and directory create/delete are atomic AFAIK. The arch/tla code uses file system semantics for locking - some study of the code w

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

On Tue, 2003-08-26 at 12:58, Albert Chin wrote: > Why not use $srcfile and "$srcfile.lock" as the lock file? So, rather > than: They may be on different fs's. Rob -- GPG key available at: . ___ Li