Re: Specifying a .def file for use with libtools libraries

2002-02-18 Thread Charles Wilson
simply ignores it as far as I can see! Stephano Mariani -Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Monday, 18 February 2002 7 14 To: Stephano Mariani Cc: [EMAIL PROTECTED] Subject: Re: Specifying a .def file for use with libtools libraries

libtool, cygwin: static archives have duplicate .o's

2002-05-02 Thread Charles Wilson
So I was building automake-1.6.1 and ran its self tests, which uncovered a bug in libtool (CVS 20020316). Automake's pr300-ltlib test: Fails in 'make install-strip' because 'strip --strip-debug' on a static library goes berzerk when the library contains two copies of the same object

Re: Proposed libtool patch for MinGW

2002-10-15 Thread Charles Wilson
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

Re: Proposed libtool patch for MinGW

2002-10-15 Thread Charles Wilson
Bob Friesenhahn wrote: The MinGW patch uses libbase-number.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

Re: Deprecate AC_LIBTOOL_WIN32_DLL?

2002-10-26 Thread Charles Wilson
Earnie Boyd wrote: Is it still true that global variables exported from a dll must have a dllimport directive for applications? AC_LIBTOOL_WIN32_DLL would perhaps indicate a package has addressed this issue (by whatever means) and is therefore dll safe. While this is required by MSVC, to my

Re: Deprecate AC_LIBTOOL_WIN32_DLL?

2002-10-26 Thread Charles Wilson
Oops. Looks like the uuencoded version of egor's stuff got scrambled. I've MIME-atteched them here. --Chuck egor-patches-example.tar.bz2 Description: Binary data long_long_example.tar.bz2 Description: Binary data

Re: Cygwin List O' Issues...[static runtime libs]

2002-10-30 Thread Charles Wilson
1. C++ (actually, all tags except C) is broken. This is because the non-C tags extract the list of runtime stdlibs from the compiler, and then explicitly add them to the link command (while using -nostdlibs). This has the effect of requiring that the runtime libs satisfy the is it

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

2002-10-30 Thread Charles Wilson
Geez, I have no idea what happened to the formatting of the preceding message... 2. 'make install DESTDIR=' fails (or relinks to an old version of a dependent lib) when the project contains dependent libraries. This bug affects all platforms. Demonstrates the problems with dependent

Re: Cygwin List O' Issues...[relinking exe's]

2002-10-30 Thread Charles Wilson
Oops. Forgot the example. --Chuck relinkprog-demo.tar.bz2 Description: Binary data

Re: Cygwin List O' Issues...[relinking exe's]

2002-10-30 Thread Charles Wilson
Charles Wilson wrote: 3. relinking .exe's. Over and over and over and over. This doesn't really cause project builds to FAIL, but it is HIGHLY annoying -- and has the possibility of an infinite dependency loop. This bug is win32-platform (cygwin, mingw, pw, ...) specific. I notice

Re: Cygwin List O' Issues...

2002-10-30 Thread Charles Wilson
Bob Friesenhahn wrote: Yes, but I only saw that once. I have not verified that it always happens. It might've been a fluke. Have you seen this 'go ahead and build the shared lib even though I just finished complaining that I couldn't' behavior, too? Yes, I have. In this particular case,

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

2002-10-30 Thread Charles Wilson
David I. Lehn wrote: Could someone -please- either let all of us know how to properly deal with this relink issue or just apply the ltmain.sh patches in the latest Debian libtool package to CVS? Or at least comment on how it should be modified if it's not acceptable. Thanks. Grab the latest

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

2002-10-30 Thread Charles Wilson
Heh... just need the ltmain.sh part. Use filterdiff from patchutils: zcat libtool_1.4.3-2.diff.gz | filterdiff -i \*ltmain.sh Patch attached. It just patches ltmain.sh... I haven't looked to see if there are other related fixes. Notice also the exit 1 vs continue when a relink fails... is

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

2002-10-30 Thread Charles Wilson
Charles Wilson wrote: A little digging in the debian bug archives (I'm not a debian user, so this is all new to me...) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=57087 reveals a reference that Ossama Othman (debian libtool maintainer) submitted a similar patch on Jul 10 2002: http

Cygwin List O' Issues (take 2): #4 complain-then-attempt-anyway RESOLVED

2002-11-01 Thread Charles Wilson
this problem has been resolved. See patch on libtool-patches. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Cygwin List O' Issues (take 2): #2 make install DESTDIR= RESOLVED

2002-11-01 Thread Charles Wilson
this problem has been resolved. See patch on libtool-patches. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: Cygwin List O' Issues...

2002-11-01 Thread Charles Wilson
Charles Wilson wrote: Bob Friesenhahn wrote: Yes, but I only saw that once. I have not verified that it always happens. It might've been a fluke. Have you seen this 'go ahead and build the shared lib even though I just finished complaining that I couldn't' behavior, too? Yes, I have

Re: [shell functions, was RE: solving of name conflicts in included . a]

2002-11-07 Thread Charles Wilson
. No flames from me. I actually brought this issue up when I submitted my patches: Charles Wilson wrote: Since $file_magic_cmd is called with different arguments ($file_magic_test_file in one place, \\$potlib\ in another), we need some construct that can take an argument, and then run

Re: [shell functions, was RE: solving of name conflicts in included . a]

2002-11-07 Thread Charles Wilson
Bob Friesenhahn wrote: Shall libtool-1.5 require autoconf-2.56? I don't see that introducing shell functions into libtool has any bearing on the version of autoconf that libtool requires. The argument you pose is political rather than technical. Yes. The decision itself is a political

Re: CVS libtool package issues

2002-11-18 Thread Charles Wilson
Bob Friesenhahn wrote: Also, check the 'In the Near Term section here: http://www.gnu.org/software/libtool/future.html Of the four bullet points, AFAIK only one (Robert Collins...) has actually been achieved. This page seems to be rather out of date. Okay, but it duplicates a lot of what

DESTDIR installs

2002-11-25 Thread Charles Wilson
Ummm, if I understand your problem, this has been fixed in CVS HEAD: http://mail.gnu.org/pipermail/libtool-patches/2002-November/002159.html and following thread. However, it was never committed on the 1.4.x branch, even though it was submitted prior to the 1.4.3 release. Unfortunately,

Re: [Mingw-users] Re: Solving the relink exe's libtool problem[take3]

2003-01-20 Thread Charles Wilson
Bruce Korb wrote: Earnie Boyd wrote: This patch passes my test. What do we need to do to get this accepted into libtool cvs HEAD? + newargz[0] = xstrdup(/bin/sh); This may not be the shell and there is no point allocating it. It is fine to use it from static memory. Okay, the second

Re: 1,000 year backward compatability of tools

2003-02-19 Thread Charles Wilson
Bruce Korb wrote: Paul Eggert wrote: Alex Hornby [EMAIL PROTECTED] writes: On a related note, does the restriction of not using shell functions in autoconf macros still remain, For Autoconf itself, we still avoid shell functions. But of course you can use shell functions in your own

Re: bug in libtool --mode=install with EXEEXT

2003-02-27 Thread Charles Wilson
This is obviously correct; please check in. I'm sorry I missed this, when I submitted the original patch. I'll go hide, now. --Chuck Schleicher Ralph (LLI) wrote: 2003-02-27 Ralph Schleicher [EMAIL PROTECTED] * ltmain.in: Only append a dot to the wrapper script when

Re: libtool and cl

2003-03-29 Thread Charles Wilson
Braden McDaniel wrote: It used to be supported by libltdl, but when GCC implemented the auto-import capability, Gary removed the support. I think it was a bad idea to remove the support. There are plenty of reasons to use the Microsoft compiler rather than GCC under Windows since GCC has

Re: DESTDIR trouble

2003-07-05 Thread Charles Wilson
Bernd Jendrissek wrote: I realise this may be an FAQ candidate, but I haven't gotten any joy out of google or the mail.gnu.org archives. My problem: I have, say, guile 1.4 installed, with libguile.so.9 in /usr/lib. Now I've tried to build guile 1.6.4 with a DESTDIR=foo install, but then things

Re: Is libtool being maintained at all?

2003-07-06 Thread Charles Wilson
Scott James Remnant wrote: On Sun, 2003-07-06 at 11:18, Dalibor Topic wrote: http://ftp.debian.org/debian/pool/main/libt/libtool/libtool_1.4.3-10.diff.gz etc. As the Debian Libtool package maintainer, I'd like to know whether it would be possible to gain CVS commit access to the libtool

Re: (With Patch) Re: DESTDIR trouble

2003-07-07 Thread Charles Wilson
Alexandre Duret-Lutz wrote: R For several _YEARS_, packagers for software were very troubled because R of not-completely-working staging install. I really hope this issue can R be sorted out, once and for all. One way to address the once for all part would be to write a test case. I don't

Re: DESTDIR trouble

2003-07-07 Thread Charles Wilson
Bernd Jendrissek wrote: I get this: /tmp/destdir-relinklib-demo-1.0.1: LD_LIBRARY_PATH=/tmp/relinkdemo/usr/lib ldd /tmp/relinkdemo/usr/lib/libtwo.so.1.1.1 libone.so.2 = /tmp/relinkdemo/usr/lib/libone.so.2 (0x40002000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x40012000)

Re: Is libtool being maintained at all?

2003-07-13 Thread Charles Wilson
Bob Friesenhahn wrote: A fork is totally unnecessary. Libtool maintainers seem to ebb and flow like the tide. Perhaps we are simply in an ebb period at the moment. Yes, it appears so. Personally, I was suprised at the relative lack of activity after 1.5.0 was released. (Sure, there were

relink command needs --tag

2003-08-14 Thread Charles Wilson
I'm not sure exactly where in libtool to put this, so I can't provide a patch. However, see the attached testcase... This testcase -- and the original problem -- were discovered on a cygwin system (so you'll see references to .dll's) but the problem should also occur on linux/etc. I stumbled

Re: CVS libtool fails under MinGW 1.0

2003-10-13 Thread Charles Wilson
Bob Friesenhahn wrote: Libtool (probably the 1.5 release) did used to work under MinGW. A recent libtool from CVS does not work properly under MinGW. The symptom is that libtool checks a DLL's validity using the 'file' command. This fails so use of the DLL library is rejected. The MinGW MSYS

libtool HEAD doesn't build on cygwin

2004-07-07 Thread Charles Wilson
loader-loadlibrary.c: In function `sys_wll_open': loader-loadlibrary.c:98: error: dereferencing pointer to incomplete type loader-loadlibrary.c:104: error: dereferencing pointer to incomplete type loader-loadlibrary.c:109: error: dereferencing pointer to incomplete type This is because the windows

Re: Ping: Cygwin libtool / assembler problem with -DPIC

2004-10-14 Thread Charles Wilson
Gerrit P. Haase wrote: Noah Misch wrote: There was a thread about this general topic awhile ago. That GMP actively uses -DPIC to select the correct assembly came up: http://lists.gnu.org/archive/html/libtool/2003-01/msg00060.html I saw that -DPIC was used on Cygwin to compile assembly and it

Re: cygwin coreutils-5.3.0-4 rm change breaks Libtool

2005-04-12 Thread Charles Wilson
Eric Blake wrote: Working around the problem isn't hard, just comment out the offending rm line in Libtool's ltmain.sh, Which line? Since you already found the culprit, pointing others to the location would be helpful. Can you come up with a simple libtool patch? I know where. Actually, I'd

branch 2.0, make install DESTDIR=

2005-07-10 Thread Charles Wilson
is broken -- at least on cygwin, but probably everywhere. ( cd ../libltdl /bin/sh /usr/src/libtool/devel/CVS/libtool-b2.0/config/missing --run tar chf - COPYING.LIB README Makefile.am Makefile.in argz_.h argz.c configure.ac configure libltdl/lt__alloc.h libltdl/lt__dirent.h

Re: branch 2.0, make install DESTDIR=

2005-07-11 Thread Charles Wilson
Ralf Wildenhues wrote: (B) cygwin-specific: There is no root user. There might be a SYSTEM user which is somewhat similar, and Administrator which is somewhat similar in other ways -- but regardless there is no facility to do CHOWN unless you're building as Administrator (not SYSTEM).

RE: Libtool API suggestion: LTDL_SHLIB_PRE and/or char*ltdl_map_shared_n

2005-09-09 Thread Charles Wilson
* Alexandre Oliva wrote on Thursday, September 08, 2005 22:13 CEST: On Aug 23, 2005, Albert Chin [EMAIL PROTECTED] wrote: I don't know of any linker that searches for say foo.a when given -lfoo. Uhm, how about ld? 'info ld' reveals... For instance, when ld is called with the argument

libtool-HEAD, 20051007, cygwin

2005-10-08 Thread Charles Wilson
I ran into an oddity with 'make dist' recently: I bootstrapped, compiled, and ran the testsuite[*] on libtool cvs HEAD and got the expected results (see attached). I then did a 'make dist' (after hand-editing the top-level Makefile to remove references to fcdemo, as I do not have f90

Re: Unhelpful behaviour on Cygwin when file isn't installed

2006-03-04 Thread Charles Wilson
Olly Betts wrote: Does the cygwin packaging chooser have the concept of dependencies? Yes. I've only used it briefly once some time ago, and I can't remember much about it. But if it does, then libtool should really depend on file. The official libtool package for cygwin (e.g. the one you

export_symbols_cmds erroneously expanded

2006-12-11 Thread Charles Wilson
When building pcre (which uses libtool --export-symbols-regex) I get the following error (libtool cvs branch 1.5, 20061014 checkout): /bin/sh ./libtool --mode=link gcc -export-symbols-regex '^[^_]' -I. -I/c/msys/1.0/local/src/pcre/cygports/pcre-6.7-1/src/pcre-6.7 -rpath /usr/lib -no-undefined

Re: export_symbols_cmds erroneously expanded

2006-12-11 Thread Charles Wilson
On Mon, 11 Dec 2006 18:36:56 +0100, Ralf Wildenhues [EMAIL PROTECTED] said: Hello Charles, Thanks for the bug report. [[ bug report and export_filter variable fix snipped ]] The above looks like a cleaner approach to me than the second one you offer; but it means we'd need to change

Re: export_symbols_cmds erroneously expanded

2006-12-11 Thread Charles Wilson
On Tue, 12 Dec 2006 01:03:41 +0100, Ralf Wildenhues said Or we need to make sure the extra expansion does not matter. Arguably, this is a hack, but in practice it may be enough for now. I had to create a directory /s to expose the bug -- do you have an S: drive? Hmm. As a matter of fact, I

Re: export_symbols_cmds erroneously expanded

2006-12-14 Thread Charles Wilson
there is a 'S:' drive. Report by Charles Wilson. Yep, that fixes the problem too: tested on both cygwin and mingw. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool

[cygwin] Analysis for new testsuite failures 33,34.35

2007-03-24 Thread Charles Wilson
In this message: http://lists.gnu.org/archive/html/libtool-patches/2007-03/msg00030.html I mentioned that I had observed three new failures in the testsuite: 33,34,35: new regressions in CVS between 20070205 and 20070316 I think the CVS dates are a red herring. The error message in

Re: [RFC] New library type needed?

2007-03-26 Thread Charles Wilson
Charles Wilson wrote: I completely understand the motivation for the meat of this, speaking in the hypothetical sense, but why would you ever want to build libbfd shared? I did --enable-shared at the top level, and bfd is the first one that failed. I'm really more interested in the runtime

Re: [cygwin] Analysis for new testsuite failures 33,34.35

2007-03-26 Thread Charles Wilson
[EMAIL PROTECTED] wrote: On Mon, 26 Mar 2007 20:39:24 +0200, Ralf Wildenhues said: AFAICS, this can only happen if libltdl was treated with automake-1.9 and the tests run with automake-1.10 in place, so that the toplevel package (named subproject-demo-2.1a) is treated with 1.10. I'm not so

Re: [RFC] New library type needed?

2007-03-28 Thread Charles Wilson
of them. Agreed. While I was considering the problem, I kept getting the feeling that either (1) I was missing something, or (2) this was very win32 specific: it's a problem only for platforms that require -no-undefined for shared libraries, which I think is only win32 and AIX. * Charles Wilson

Simultaneous pic and non-pic convenience libs [Was: [RFC] New library type needed?]

2007-03-31 Thread Charles Wilson
Charles Wilson wrote: I'd still like to be able to build my convenience library as both pic and non-pic tho. And I still want to prevent libiberty.a(non-pic) from getting the --whole-archive treatment when it comes to libbfd.a. ... Several systems simply don't allow to mix PIC and non-PIC

Re: .exe magic

2007-04-18 Thread Charles Wilson
[added libtool to CC list] Corinna Vinschen wrote: On Apr 18 04:49, Charles Wilson wrote: The current .exe behavior has benefited from many years of tweaking and fine-tuning, across many different packages (cygwin, gcc, gdb, binutils, automake, autoconf, libtool, bash, coreutils, ...) to work

[cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source [Was: Re: .exe magic]

2007-04-18 Thread Charles Wilson
[Added libtool-patches to CC list. Discussion of this patch should probably drop libtool and cygwin] Ralf Wildenhues wrote: * Charles Wilson wrote on Wed, Apr 18, 2007 at 08:49:31PM CEST: Caveat: over a year after the message referenced above, but libtool2.0 is STILL in code-slush, so

Re: [PATCH] Don't install .la files when --no-la-files is used

2008-11-08 Thread Charles Wilson
Roumen Petrov wrote: Linking readline against ncurses prevent application to link against readline against ncursesw and to offer wide characters support. Note that this is only even possible on a system with lazy binding. For windows, shared libraries cannot have any undefined symbols at link

Re: problem when cross compiling with mingw32ce

2009-01-21 Thread Charles Wilson
Vincent Torri wrote: here is a reminding of something that i reported 2 months ago: (see http://lists.gnu.org/archive/html/libtool/2008-11/msg00147.html). I recall the facts: when using the mingw32ce compiler, func_emit_cwrapperexe_src() fails, hence the installation of the binaries is not

Re: problem with libtool under windows and cygwin

2009-04-09 Thread Charles Wilson
Andreas Otto wrote: as special restriction I use the build-tools from cygwin but it is no cygwin library at all because I use the build-in mingw compiler gcc -mno-cygwin This is *not* a built-in mingw compiler. It's a hack that sometimes works, but always causes problems.

Re: purpose of the c wrapper

2009-06-03 Thread Charles Wilson
Ralf Wildenhues wrote: (On most w32 systems, a script without an .exe extension would match such a rule as well, but that's not the case for example on GNU/Linux - w32 cross compiles and with some weird Cygwin mount options.) ...such as the default (only) mount mode under the upcoming

Different object lists for static and shared libraries

2009-06-27 Thread Charles Wilson
I have a library that I'm building using libtool. When built statically, I want it to include a certain list of object files. When linking that library dynamically, I want to add an additional object (windows resources, compiled using windres). I already have it working so that BOTH versions get

Re: Different object lists for static and shared libraries

2009-06-28 Thread Charles Wilson
Ralf Wildenhues wrote: * Charles Wilson wrote on Sun, Jun 28, 2009 at 12:54:59AM CEST: Is there a better way? Not that I know of. The current code might cause the object list for the static library to be a larger set than that for the shared library (because it won't add objects compiled

Creating shared and static libraries with convenience libraries

2009-06-28 Thread Charles Wilson
I ran in to a problem using libtool to generate both shared and static libraries with convenience archives (on cygwin, but I believe this is cross-platform). Working with git-master xz utils, with some local patches, I saw the following: /bin/sh ../../libtool --tag=CC --mode=link gcc

Re: libtool versioning and ABI

2009-08-11 Thread Charles Wilson
Michel Briand wrote: This last variable is crafted crafted? This is your mistake. to reflect the usual versioning. I.e. if I want the version to 1.22.5, Why? Why do you CARE what the internal ABI version number is? It's just a tag; you shouldn't care WHAT it is, only that it changes ONLY

Re: libtool versioning and ABI

2009-08-11 Thread Charles Wilson
Michel Briand wrote: Thank you, but, sorry, I'm not convinced. Remember what I said a few mails ago: that's all of interface contract = same concept as your... Does anyone uses 10 or 16 to refer to their ABI ? Hum... So those numbers have to be managed somewhere... Yes. Here are a few

Re: libtool versioning and ABI

2009-08-11 Thread Charles Wilson
Michel Briand wrote: libavutil49-0.4.9-3.pre1.8994.2plf2008.0 ABI=49, pkgver=0.4.9 Please give me the way to learn those ABI number you cite. libavutil49-0.4.9-stuff ^^ is usually used by the distribution (Red Hat? Debian?) to indicate that

Re: GNU Libtool 2.2.8 released (stable)

2010-06-08 Thread Charles Wilson
On 6/8/2010 2:46 AM, Gary V. Vaughan wrote: [[Adding Libtool List]] On 8 Jun 2010, at 08:56, Charles Wilson wrote: What happens if libltdl is used to load (say) libtiff which has an automatic dependency on libjpeg? The initial LoadLibrary from libltdl pulls in libtiff.dll AND libjpeg.dll

Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]

2010-06-08 Thread Charles Wilson
On 6/8/2010 6:47 AM, Christopher Hulbert wrote: Peter/Charles, Do you have a summary of the capabilities added by your patches/branch I'll let Peter speak for himself, but these are the patches in the cygwin and mingw distributions: * Pass various runtime library flags to GCC.

Re: pr-msvc-support merge

2010-06-19 Thread Charles Wilson
On 6/16/2010 8:30 AM, Peter Rosin wrote: It was the easiest I could come up with after experimenting a lot. That wasn't yesterday though, but IIRC if you want to convert paths with spaces, you need to quote the $path for cmd, hence the quotes in the echo $path construct. The space before the

Re: 2.4 Release in 24hrs

2010-09-19 Thread Charles Wilson
On 9/19/2010 11:45 AM, Bob Friesenhahn wrote: Unfortunately, my MinGW testing is not so successful. The testing still quits part-way through with some sort of make-related issue (as reported in detail previously). Odd. My last test on MinGW was very successful. This was version 1.3266

Re: 2.4 Release in 24hrs

2010-09-19 Thread Charles Wilson
On 9/19/2010 3:27 PM, Bob Friesenhahn wrote: The 'make' used is GNU make 3.79.1. Yikes. Where did THAT come from? MSYS has provided at least make-3.81 for several years; the current msys make is 3.82. There is a 'mingw32-make' which is GNU make 3.82, but does not seem to work under MSYS.

Re: 2.4 Release in 24hrs

2010-09-19 Thread Charles Wilson
On 9/19/2010 12:57 PM, Charles Wilson wrote: On 9/19/2010 11:45 AM, Bob Friesenhahn wrote: Unfortunately, my MinGW testing is not so successful. The testing still quits part-way through with some sort of make-related issue (as reported in detail previously). Odd. My last test on MinGW

Re: 2.4 Release in 24hrs

2010-09-20 Thread Charles Wilson
On 9/20/2010 11:31 AM, Bob Friesenhahn wrote: On Sun, 19 Sep 2010, Charles Wilson wrote: MinGW/MSYS: old -- All 122 tests passed (2 tests were not run) new -- 108 tests behaved as expected. 12 tests were skipped. With Charles Wilson's assistance, I updated my MinGW environment

Re: 2.4 Release in 24hrs

2010-09-21 Thread Charles Wilson
On 9/20/2010 1:41 PM, Ralf Wildenhues wrote: I'd really appreciate if you guys could send build logs to the autobuild server... Here's what I use, more or less, to create the logs: ( ../libtool/configure [OPTIONS] \ make \ make -k check cat test-suite.log

Re: 2.4 Release in 24hrs

2010-09-21 Thread Charles Wilson
On 9/21/2010 9:21 PM, Gary V. Vaughan wrote: I don't recall having done so in a while but, according to bootstrap: # It is okay for the bootstrap process to require unreleased autoconf # or automake, as long as any released libtool will work with at least # the newest stable versions of

Re: bogus warning 'seems to be moved'

2010-09-23 Thread Charles Wilson
Just FYI... I don't think the following scenario applies to either of you, but I ran into the warning in the case described below -- and the warning is valid (e.g. we shouldn't try to fix MY case). I was using a cross compiler with sysroot support (cygwin-mingw) to build cygwin's setup.exe. I

Re: bogus warning 'seems to be moved'

2010-09-23 Thread Charles Wilson
On 9/24/2010 12:45 AM, Marco Atzeri wrote: I am not sure to follow your explanation. on cygwin $cd /usr/lib I'm cross building, using $build_os=cygwin, but $host_os=mingw32, and a cross compiler. I am *not* building natively. In this situation, and with the new sysroot support in

Re: GNU Libtool 2.4 released [stable]

2010-09-30 Thread Charles Wilson
On 9/30/2010 7:19 AM, Paolo Bonzini wrote: Note that it's perfectly possible to use .la files on the final system that didn't go through libtool --mode=finish, as long as all the packages you compile are upgraded to Libtool 2.4 (and IIUC, cygwin's packaging system for example is already

Re: GNU Libtool 2.4 released [stable]

2010-10-01 Thread Charles Wilson
On 10/1/2010 4:22 PM, Alon Bar-Lev wrote: On Fri, Oct 1, 2010 at 3:35 PM, Charles Wilson please-don't-feed-the-spammers wrote: ^^^ Please, over the past three months there were hundreds of messages discussing sysroot and how it shoold be handled. While

Re: DLL creation and static libs

2010-11-02 Thread Charles Wilson
On 11/2/2010 2:14 AM, Ralf Wildenhues wrote: OTOH, if the w32 maintainers agree, then we can also give in and allow linking against static libraries plainly. I tried the trivial patch (set deplibs_check_method to pass_all) a while ago but that caused a number of test failures, so somebody

Re: -no-undefined vs gcc 4.6.0

2011-03-19 Thread Charles Wilson
On 3/19/2011 6:25 AM, LRN wrote: I expect to find a lot of libtool-using projects that will require such hacks or workarounds, because `unrecognized option '-no-undefined'' is very common. Ah, but actually -no-undefined should be added by the upstream maintainers, in Makefile.am, to

Re: Shared library versioning

2011-06-16 Thread Charles Wilson
On 6/16/2011 2:50 PM, Lasse Collin wrote: About -version-info vs. -version-number: *If* it turns out that all operating systems supported by Libtool should use a versioning style that is essentially the same as version_type=linux, could -version-number become the recommended option to set

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-17 Thread Charles Wilson
On 6/17/2011 3:46 AM, Marco atzeri wrote: on cygwin lt_cv_deplibs_check_method=pass_all is my workaround at configure stage to bypass incorrect libtool detection of system capabilities and to allow shared libs building. It's not about system capabilities in this case. It's about the fact

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-17 Thread Charles Wilson
On 6/17/2011 11:03 AM, Marco atzeri wrote: Sorry Chuck, but I can assure you that I am linking against shared dlls, but the detection is incorrect. Well, then that's a bug. Can you give an example of a foo.a, foo.dll.a, and foo-N.dll (plus the -lfoo incantation) you're using for which the

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-18 Thread Charles Wilson
On 6/17/2011 10:19 AM, Vadim Zeitlin wrote: On Thu, 16 Jun 2011 19:10:39 -0500 (CDT) Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: BF Most projects using libtool come from Unix/Linux where auto-import BF is the default so it can be seen that most projects already depend on BF it

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-20 Thread Charles Wilson
On 6/20/2011 3:32 AM, Marco atzeri wrote: Hi Chuck, I guess func_win32_libid() is not failing but the gcc/linker is smarter than libtool expect; or that autoconf is misleading libtool. /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.a /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.dll.a

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-21 Thread Charles Wilson
On 6/21/2011 8:29 AM, Vadim Zeitlin wrote: Charles Wilson don't feed spammers writes: No, I think --disable-static, if specified, should actually *disable static*. That should be sufficient. If it's not doing that, then it's a bug IMO. Just to confirm: no, currently it doesn't do

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-23 Thread Charles Wilson
On 6/23/2011 11:03 AM, Vadim Zeitlin wrote: On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: BF On Thu, 23 Jun 2011, Vadim Zeitlin wrote: BF BF I.e. it created a shared library with undefined symbols without any BF problems because it never

Re: Obsoleting LT_SCOPE

2011-10-25 Thread Charles Wilson
On 10/25/2011 6:51 AM, Gary V. Vaughan wrote: Do you forsee any issues on Windows with my doing that? Yes. I'm almost certain that modern gcc and hence cygwin and variants will continue to work correctly without LT_SCOPE, LTDL_DLL_IMPORT and friends, but I have no clue whether vendor

Re: Obsoleting LT_SCOPE

2011-10-25 Thread Charles Wilson
On 10/25/2011 11:03 AM, Peter Rosin wrote: Gary V. Vaughan skrev 2011-10-25 14:17: I configures both the way I usually configure libtool for msvc, i.e. ../configure autobuild_mode=msvc CC=/c/cygwin/home/peda/automake/lib/compile cl CFLAGS=-MD -Zi -EHsc

Re: Obsoleting LT_SCOPE

2011-10-25 Thread Charles Wilson
On 10/25/2011 11:51 AM, Gary V. Vaughan wrote: I have to bow to your superior knowledge of Windows, which I haven't used for development since Windows NT 4, but it feels weird that Libltdl really does twist itself into a pretzel for Windows... and yet all the other GNU projects I've looked at do

Re: cross compilation to w32

2008-03-08 Thread Charles Wilson
Ralf Wildenhues wrote: Does anybody see easy ways out? Well, for the second problem there are two solutions. (1) always ensure that the script is emitted with unix line endings, or (2) specify $TARGETSHELL=/emulation/environment/sh when cross-compiling. Obviously, (2) is the easiest,

libtool ChangeLog libltdl/config/ltmain.m4sh

2007-06-07 Thread Charles Wilson
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson07/06/07 08:47:12 Modified files: . : ChangeLog libltdl/config : ltmain.m4sh Log message: * ltmain.m4sh (func_emit_libtool_wrapper_script): add

libtool ChangeLog libltdl/config/ltmain.m4sh

2007-06-07 Thread Charles Wilson
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson07/06/07 08:50:17 Modified files: . : ChangeLog libltdl/config : ltmain.m4sh Log message: * ltmain.m4sh (func_emit_libtool_cwrapperexe_source

libtool ChangeLog libltdl/m4/libtool.m4

2007-06-17 Thread Charles Wilson
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson07/06/17 20:16:04 Modified files: . : ChangeLog libltdl/m4 : libtool.m4 Log message: * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): ensure stderr

libtool ChangeLog libltdl/config/ltmain.m4sh te...

2007-06-18 Thread Charles Wilson
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson07/06/19 05:43:16 Modified files: . : ChangeLog libltdl/config : ltmain.m4sh tests : destdir.at Log message: * libltdl/config

libtool AUTHORS ChangeLog

2007-06-19 Thread Charles Wilson
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson07/06/19 06:22:02 Modified files: . : AUTHORS ChangeLog Log message: * AUTHORS: Add myself. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/libtool

libtool ChangeLog libltdl/config/ltmain.m4sh li...

2007-07-13 Thread Charles Wilson
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson07/07/13 07:21:39 Modified files: . : ChangeLog libltdl/config : ltmain.m4sh libltdl/m4 : libtool.m4 Log message: * libltdl/m4/libtool.m4

libtool ChangeLog tests/cdemo-exec.test tests/d...

2007-07-16 Thread Charles Wilson
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson07/07/16 22:53:06 Modified files: . : ChangeLog tests : cdemo-exec.test demo-deplibs.test demo-exec.test demo-inst.test demo

libtool ChangeLog libltdl/config/ltmain.m4sh

2008-03-12 Thread Charles Wilson
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson08/03/13 04:46:09 Modified files: . : ChangeLog libltdl/config : ltmain.m4sh Log message: * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src) [file

[SCM] GNU Libtool branch, master, updated. v2.2.4-3-ga50bd8f

2008-05-07 Thread Charles Wilson
a50bd8f5bf1d358353b34f42fa75c43938f26984 Author: Charles Wilson [EMAIL PROTECTED] Date: Mon May 5 20:23:05 2008 -0400 Ensure $OBJDUMP is defined * libltdl/m4/libtool.m4 (_LT_DECL_OBJDUMP): new macro ensures that $OBJDUMP is always defined sanely. (_LT_SYS_DYNAMIC_LINKER): call it. (_LT_CHECK_MAGIC_METHOD

[SCM] GNU Libtool branch, master, updated. v2.2.4-5-gfae9496

2008-05-13 Thread Charles Wilson
fae94962aa3c36f3cee00a453c2a7d01baaf4ff0 Author: Charles Wilson [EMAIL PROTECTED] Date: Sat Apr 26 16:03:50 2008 -0400 [mingw|cygwin] Modify cwrapper to invoke target directly. * libltdl/config/ltmain.m4sh (func_to_native_path): New function. If $host is mingw, and $build is mingw or cygwin, convert path

[SCM] GNU Libtool branch, master, updated. v2.2.4-11-g0e72f57

2008-05-25 Thread Charles Wilson
0e72f5793bec9624d80261f3cfc1103bb1ca82e7 Author: Charles Wilson [EMAIL PROTECTED] Date: Sun May 25 00:13:04 2008 -0400 Cwrapper should not eat -- arguments * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src) [file scope]: Defined all option strings in terms of macro LTWRAPPER_OPTION_PREFIX. Similarly

[SCM] GNU Libtool branch, master, updated. v2.2.4-12-gaf3b8c5

2008-05-25 Thread Charles Wilson
af3b8c515e1e6297294c0c5fb69998274d389653 Author: Charles Wilson [EMAIL PROTECTED] Date: Thu May 15 00:07:50 2008 -0400 [mingw] Add cross-compile support to cwrapper * libltdl/config/ltmain.m4sh (func_to_host_path) [$host=mingw]: If present, use winepath to convert from $build to $host if $build is neither

[SCM] GNU Libtool branch, master, updated. v2.2.6-37-g87cea4b

2008-11-21 Thread Charles Wilson
87cea4bf9e8341df8a317f8971fcccdad0cca9f3 Author: Charles Wilson [EMAIL PROTECTED] Date: Sat Nov 15 04:40:26 2008 -0500 Fix --verbose option; add new --no-{silent|quiet|verbose} options. * libltdl/config/ltmain.m4sh (usage): Document new options --no-silent/--no-quiet and --no-verbose. (func_enable_tag

  1   2   3   4   5   6   >