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're being installed
libtool.m4 in cvs says:
if test "$GCC" = yes; then
sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:"
| sed -e "s/^libraries://" -e "s,=/,/,g"`
When this runs on MacOS X 10.2 (with August 2002 developer tools), it
gets only one search dir rather than the whole set of dirs
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://ma
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 <[EMAIL PROTECTED]> [20021030 21:20]:
> 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?
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
* Charles Wilson <[EMAIL PROTECTED]> [20021030 20:23]:
> >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.
>
> Demonstrate
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,
On Wed, 30 Oct 2002, Charles Wilson 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 bug
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
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 that Ear
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
On Wed, 30 Oct 2002, Charles Wilson wrote:
>
> -
> 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
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
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
There's a problem in that libtool directs the binary output to the .libs
directory with a script built to execute the binary. The script does
not and cannot have the .exe extention. So the question is, how to go
about resolving the issue?
The issue is the fact that the make target is modified
17 matches
Mail list logo
