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
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
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
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
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
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
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
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
Oops. Forgot the example.
--Chuck
relinkprog-demo.tar.bz2
Description: Binary data
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,
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
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
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
this problem has been resolved. See patch on libtool-patches.
--Chuck
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
this problem has been resolved. See patch on libtool-patches.
--Chuck
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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
.
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
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
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
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,
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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).
* 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
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
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
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
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
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
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
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
[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
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
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
[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
[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
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
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
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.
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
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
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
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
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
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
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
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
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.
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
805585f7bffadb85259a3db72a7d368a99e6966c
Author: Charles Wilson libt...@cwilson.fastmail.fm
Date: Tue Jan 20 17:31:43 2009 -0500
Minor cygwin cleanup
libltdl/config/ltmain.m4sh (func_generate_dlsyms): Correct
case pattern for cygwin
eaba16eb3a54b27704799d5bfd2619f6732225ce
Author: Charles Wilson libt...@cwilson.fastmail.fm
Date: Sat Jan 24 12:04:45 2009 -0500
Add -Wall to cwrapper tests.
* tests/cwrapper.at: Add -Wall existing tests. Add additional
round of tests with -Wall alone
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 0980a3993a6138895d4884f92ff9764d426b148d (commit)
from
8965cb5fa339aa4f63d0e77fcc91e0e46929348d
Author: Charles Wilson libt...@cwilson.fastmail.fm
Date: Sun Mar 29 19:25:35 2009 -0400
Improve compatibility with older automake
* libltdl/m4/lt~obsolete.m4: Add AC_DEFUNs for
_LT_PREPARE_SED_QUOTE_VARS and _LT_PROG_ECHO_BACKSLASH.
Report by Yaakov Selkowitz
,--export-all-symbols, as required
by GNU ld for PE-COFF.
Signed-off-by: Charles Wilson libt...@cwilson.fastmail.fm
---
Summary of changes:
ChangeLog |8
libltdl/m4/libtool.m4 |1 +
2 files
1 - 100 of 542 matches
Mail list logo
