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
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 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 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 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/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/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/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 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 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/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 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 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 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 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 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 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 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
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/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
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/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/
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/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/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 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 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 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/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
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
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:
> 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
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
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
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 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:
> 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
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:
> (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
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
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
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
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
[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
[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
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
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.
*
[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
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
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
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
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
> 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
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
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
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
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
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
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
_
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
* 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
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
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
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
Gerrit P. Haase wrote:
I think it is a bad thing to add -D flags unconditionally and for sure
it is a bad thing if it is a noop.
You're missing the point. *libtool* doesn't know that -DPIC means
nothing for your code. On some platforms, you really have to compile
DIFFERENT CODE, not just compil
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 co
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
Some of the recent changes seem to have broken VPATH builds:
cd ${builddir}
${srcdir}/configure --srcdir=${srcdir} --build=${host}
--target=${target} --prefix=${prefix} --sysconfdir=${sysconfdir}
...
checking for readdir... yes
configure: creating ./config.status
config.status: creating Makefil
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 en
Gary V. Vaughan wrote:
Peter O'Gorman wrote:
I assume you mean the libtool-1.5 is not available on gnu.org since it
was hacked in March. I believe it's reappearance is waiting on a
libtool admin letting the relevant folks know the md5 checksum for
that release.
The checksum I have is 0e1844f2
Boehne, Robert wrote:
Until last week, none of us had a libtool-1.5 tarball, but now that
one has been located we can verify it for the FSF. I'm not sure
when though.
Yeesh, I had no idea. The cygwin libtool-devel-1.5 source dist is
widely mirrored, and:
Contents of libtool-devel-1.5-1.tar.bz2
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:
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 pa
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)
libc
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
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 repository
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 ge
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
limited
Laurent Marzullo wrote:
*** Warning: This system can not link to static lib archive
/cygdrive/d/Workspace/CDK/dev/cdk-db/target/lib/libcdk-db-c.la.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** sha
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
buildi
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 macr
FWIW, "current" CVS (most recent changelog entry when I checkedout was
"2003-02-04 Nick Hudson ") has no new test failures
on cygwin.
autoconf-2.57
automake-1.7.2
cygwin-1.3.18-1
gcc-3.2-3
binutils-20021117-1
the only existing testsuite failures are two longstanding ones,
build-relink2 and q
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 secon
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, 1.4.x
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 wha
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.
[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
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
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
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
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
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
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,
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
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
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
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:
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
1 - 100 of 121 matches
Mail list logo
