"Gary V. Vaughan" wrote:
> >
> > Also, there are two separate issues being discussed here: (1) how to
> > (compile-time) link against the 'right' version of a library, and (2)
> > how to insure that the 'right' dll is loaded at run-time.
>
> Nah. I'm talking about (2) only. I *am* assuming 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 liblt
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. (-shared-li
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
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
(ef5
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).
>
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
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 tests/
Peter Rosin wrote:
> Just a friendly ping, but only just now I pushed a change to the
> 'compile' script in automake and would like the new version in
> the release if it's not too much to ask for. Thanks!
Errr...is that kosher? I thought libtool was only supposed to ship the
scripts provided by
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 w
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 l
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 r
On 10/1/2010 2:23 AM, Alon Bar-Lev wrote:
> I wanted to see the process this way...
>
> export SYSROOT=/tmp/root1
>
> package1: ./configure
> package1: make install DESTDIR=/tmp/root1
>
> package2: ./configure
> package2: make install DESTDIR=/tmp/root2
What you are missing is that "sysroot" is
On 10/1/2010 4:22 PM, Alon Bar-Lev wrote:
> On Fri, Oct 1, 2010 at 3:35 PM, Charles Wilson
> wrote:
^^^
>> Please, over the past three months there were hundreds of messages
>> discussing sysroot and how it shoold be handled. While libtool'
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 11/3/2010 12:23 PM, Matěj Týč wrote:
> On 2 November 2010 13:26, Charles Wilson wrote:
>> On 11/2/2010 2:14 AM, Ralf Wildenhues wrote:
>> ...
>> the problem is there are TWO different libuuid's. There's the one that
>> is part of the win32 api, and simpl
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 libfoo
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 se
On 6/17/2011 5:26 AM, Lasse Collin wrote:
> At that point, Debian had bumped major to 2. Other distros might have
> had other versions. If I had tracked the ABI breakages in development
> versions, current in -version-info would now be close to a three-digit
> number. Probably I wouldn't have re
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 abou
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
de
On 6/17/2011 10:19 AM, Vadim Zeitlin wrote:
> On Thu, 16 Jun 2011 19:10:39 -0500 (CDT) Bob Friesenhahn
> 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
>
> My personal exper
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
> /lib/gcc/
On 6/21/2011 8:29 AM, Vadim Zeitlin wrote:
> Charles Wilson 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 con
On 6/23/2011 11:03 AM, Vadim Zeitlin wrote:
> On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn
> 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 actually passed
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 com
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" CXX="/c/cygwin/home/peda/autom
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
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 pr
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 libltdl/lt__glib
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). Basica
* 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 argu
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 installe
Ralf Wildenhues wrote:
Please post tests/testsuite.log containing the failures (packed?).
I cannot reproduce this on GNU/Linux (and you posting should be less
work than me trying to reproduce it on cygwin :)
attached.
--
Chuck
testsuite.log.bz2
Description: Binary data
_
Ralf Wildenhues wrote:
Index: tests/testsuite.at
===
RCS file: /cvsroot/libtool/libtool/tests/testsuite.at,v
retrieving revision 1.26
diff -u -r1.26 testsuite.at
--- tests/testsuite.at 11 Oct 2005 16:51:50 - 1.26
+++ tests
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 -ve
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 nee
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 fac
> double expansion, in case 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
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
tests
The problem:
===
Currently, libtool supports several types of libraries (I'm glossing
over some stuff here, be gentle):
(1) Normal shared libraries
(2) Normal static libraries
(3) Convenience libraries
(a) non-PIC -- will e
Charles Wilson wrote:
(3) where the PIC resolver library is used *like a static library* when
building dependent shared libraries -- that is, used to satisfy
undefined symbols in the shared library if -no-undefined, but where the
objects in the PIC resolver library are
NOT
included
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 ru
[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
not all 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 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 a
[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 the
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
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 proble
Brandon Philips wrote:
> Is there a way to make the libtool wrapper create an executable with
> the same "progname" as the final executable?
Not that I know of. However, the Smart People[tm] over at the gnulib
project seem to simply work around it. In the their progname module:
http://git.sava
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 cyg
Ralf Wildenhues wrote:
>> If, however, such step by step examples already exist, please point me
>> to them and, if the chapter/link with them is not yet in the documentation,
>> please put the info into documentation.
>
> Well, there isn't much in the Libtool manual at all, and only general
> in
Ralf Wildenhues wrote:
> Vincent, you're contradicting yourself over the course of this work.
> I thought at one point we got the wrapper to work on mingwce. I mean
> that's the reason we added those __MINGW32CE__ ifdefs in the first
> place. If they fail to work properly now, then we should fix
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
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 -std=gnu99
Bob Friesenhahn wrote:
> On Sun, 28 Jun 2009, Charles Wilson wrote:
>>
>> So, when we get around to linking the actually installable library, both
>> the DLL and the "static' archive contain the same .o's -- the ones
>> compiled with the "pic" f
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 ONL
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
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-
^^
is usually used by the distribution (Red Hat? Debian?) to indicate that
t
Stephano Mariani wrote:
> Hello,
>
> I am using the current libtool with cygwin 1.3.9 (all packages up to
> date as of this morning):
> libtool 20010531a-1
> libtool-devel 20020202-1
> libtool-devel-src 20020202-1
> libtool-stable 1.4.2-2
>
> My project has to run on wi
3 \3/p' | sed 's/.* //' | sort
> | uniq > .libs/libfile.exp
>
> And passes it to ld via gcc using -Wl,-retain-symbols-file
> -Wl,.libs/libfile.exp
>
> This seems flawed to me since ld simply ignores it as far as I can see!
>
> Stephano Mariani
>
>
>&g
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 f
Oops. Missed a few in that last patch:
2002-05-03 Charles Wilson <[EMAIL PROTECTED]>
* tests/pdemo-inst.test: use hell_static instead
of hell.static
* tests/pdemo-exec.test: ditto
--Chuck
Index: pdemo-exe
ally-linked executable in a directory where a previous build of
dynamically-linked exe left a wrapper script behing, well, problems
ensue. This happens often in the testsuite.
See this message and the thread following it:
http://mail.gnu.org/pipermail/automake-patches/2002-May/000785.html
Anyway, th
Bob Friesenhahn wrote:
> I am attempting to get ImageMagick to work properly using Cygwin DLLs.
> The C++ component is built as a DLL using the binutils auto-import
> feature and CVS libtool. The library works fine with the glaring
> exception that any C++ exception thrown from the library cause
Can someone with checkin priveleges please review the patches I posted
to this list last week (I tried to send them to libtool-patches five
days before THAT but couldn't as I am not subscribed).
I mentioned in the first email (of three) that you also need a fixed
automake. However, that is ne
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 current
Bob Friesenhahn wrote:
>
> The MinGW patch uses lib-.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
> overwri
When the AC_LIBTOOL_WIN32_DLL macro was originated, it was necessary
to add dllexport decorations to library source code in order to build
a DLL. When AC_LIBTOOL_WIN32_DLL was added to configure.in, it
enabled a few Windows specific tests, but most importantly, it enabled
building libraries as DLL
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 k
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
This is the first of four messages. There are three significant issues
with regards to libtool support on cygwin, even after tonight's
inclusion of the patches I submitted. I will describe these problems
briefly here, and then start three new subthreads that more completely
describe the probl
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 dynam
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 shared
Oops. Forgot the example.
--Chuck
relinkprog-demo.tar.bz2
Description: Binary data
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 n
Bob Friesenhahn wrote:
You missed mentioning one major bug related to C++. Although libtool
warns that it can't create a shared library due to depending on a
static library, libtool proceeds to try to build a shared library
anyway. This is the worst of the bugs since it results in total
failur
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 d
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:
Tim Van Holder wrote:
On Thu, 2002-10-31 at 05:38, Charles Wilson wrote:
Charles Wilson wrote:
@@ -2243,6 +2254,14 @@
add="$dir/$linklib"
elif test "$hardcode_minus_L" = yes; then
add_dir="-L$dir"
+ # Try looking first in the location we'r
Earnie Boyd wrote:
This part won't work. It's possible we need a separate case for
A:style paths. Because the rest of the patch does:
+ add_dir="-L$inst_prefix_dir$libdir $add_dir"
E.g. prepend the inst_prefix. But A:/inst_prefix/A:/usr/lib is NOT a
valid path; for A:style path
this problem has been resolved. See patch on libtool-patches.
--Chuck
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Restating the remaining issues since (a) it's a new month for the
mailman archiver (b) some issues have been resolved (yay!)
> 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 t
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,
Restating the remaining issues since (a) it's a new month for the
mailman archiver (b) some issues have been resolved (yay!)
> 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
Resolved?
See patch on libtool-patches. There are a few extensions to that patch
that could be added, but they will change current behavior -- and will
affect platforms I can't test on.
So I'm not the one to propose them. I took the conservative approach
with the patch -- "do no harm". It f
em as well.
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 argu
On the other hand, autoconf's most recent release sez (as ADL pointed
out before I finished composing this message):
** Plans for 2.56
...
- shell functions
Shell functions will gradually be introduced, probably starting with
Autotest. If yo
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
[EMAIL PROTECTED] wrote:
Let
them install BASH and get out of our way. Both of them.
Bash uses configure.
And so does ash :-( which was my first thought for working around this
problem. On the other hand, is it so terrible to ask that those who
wish to continue using systems with 20-ye
There are a number CVS libtool package issues which should be
addressed before libtool 1.5 is released.
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.
1 - 100 of 121 matches
Mail list logo
