Michael Matz wrote:
>
> Hi,
>
> On Thu, 5 Apr 2001, edward wrote:
>
> > how about a sub-optimal (but at least an) improvement?
> >
> > something along the lines of
> ... loop to remove consecutive duplicates.
> >
> > This cuts down on all the extraneous stuff *safely*, i think.
>
> Yep, This i
Hi!
I found this in libtol/Changelog
2001-03-31 Gary V. Vaughan <[EMAIL PROTECTED]>
* ltmain.in: Remove the code for stripping duplicate deplibs
from libtool link lines -- duplicates are somtimes necessary
to satisfy inter-library dependencies, and never cause link to
"Wesley W. Terpstra" wrote:
>
> I would like to run:
> libtool c++ -o foo.lo foo.cc
> libtool c++ -o bar.lo bar.cc
> libtool c++ -o libfoo.la foo.lo -rpath /usr/lib
> libtool c++ -o libbar.la bar.lo libfoo.la -rpath /usr/lib
>
> But, the last command yields:
> libtool: link: error: cannot link s
Hi!
The following patch adds paths to dependent libs in end of the
link line instead in front. The patch looks weired, but right after
the order is reordered :)
This fixes my problem I posted before.
Greetings, Stephan
Index: ltmain.in
==
Ossama Othman wrote:
>
> Hi Stephan,
>
> The following patch should be better:
>
Hi!
OK, your patch doesn't heal the problem and now that the deps are so
much clearer,
I think it's clear that the ml stuff isn't to blame per se :)
/bin/sh ../libtool --mode=link g++ -g -ansi -D_XOPEN_SOURCE
-D
Ossama Othman wrote:
>
> Hi Stephan,
>
> You're too quick. :-)
>
> I'm testing a different patch which should be better, and incurs less
> overhead during link-time, since it is run at config-time.
>
> On Sun, Jun 04, 2000 at 01:12:53AM +0200, Stephan
Ossama Othman wrote:
>
> Hi,
>
> There was a slight bug in the patch I just posted, but I think that
> you get the idea of what it was supposed to do.
You were talking about the the, no? :)
OK, it doesn't work.
I patched your patch to have some debug output:
+ echo "new_predeps $new_pred
Ossama Othman wrote:
>
> Hi Stephan,
>
> On Fri, Jun 02, 2000 at 09:46:59PM +0200, Stephan Kulow wrote:
> > Ossama Othman wrote:
> > > Since many of you are using the libtool multi-language branch, I
> > > wanted to check with you about switching that bran
Ossama Othman wrote:
>
> Hi,
>
> Since many of you are using the libtool multi-language branch, I
> wanted to check with you about switching that branch to use CVS
> autoconf and CVS automake. I have some patches ready for approval
> (i.e. I haven't submitted them for approval yet), but if ther
Hi!
This happens with the multi-language-branch:
/bin/sh ../libtool --mode=link g++-L/usr/X11R6/lib
-L/home/coolo/prod/qt/lib
-L/home/coolo/prod/KDE/lib -o dcopserver.la -rpath
/home/coolo/prod/KDE/lib -module
-avoid-version dcopserver.lo libDCOP.la
rm -fr .libs/dcopserver.la .libs/dcopserv
Ossama Othman wrote:
>
> Hi Kevin,
>
> On Sun, May 28, 2000 at 07:37:11PM -0400, Kevin Atkinson wrote:
> > I was just informed that the HEAD branch does indeed drop static library
> > dependencies when making shared libraries. Perhaps the HEAD branch needs
> > to be merged with the ML branch or
Ossama Othman wrote:
>
> Hi Stephan,
>
> On Sat, May 27, 2000 at 10:10:44AM +0200, Stephan Kulow wrote:
> > Kevin Atkinson wrote:
> > >
> > > Hopefully since KDE will be using it some KDE people will help to improve
> > > the C++ support. I am sur
Kevin Atkinson wrote:
>
> Hopefully since KDE will be using it some KDE people will help to improve
> the C++ support. I am sure they will run into the problem with non-pic
> static libraries being linked into shared libraries also. Especially on
> Solaries.
>
If you look at http://bugs.kde.or
Hi!
the soname wasn't set when -retain-symbols-file was used which broke
using this library as the linker looked in .libs even if the lib was
installed.
Here is the patch
Greetings, Stephan
diff -u -r1.2.2.5 -r1.2.2.6
--- ltcf-cxx.sh 2000/02/26 14:25:59 1.2.2.5
+++ ltcf-cxx.sh 2000/05/23 11
Hi!
Michael Matz and I plan to switch our libtool version to
the one in multi-language-branch in two days so it gets
some testing before we release KDE 2.0 with it.
The problem I see is the FIXME rate in ltcf-cxx.sh and
I wonder, if it wouldn't make more sense to default to
the most common used
Thomas Leitner wrote:
>
> Hello,
>
> I'm porting KDE 1.90 to Tru64 and needed to make the following changes
> to the libtool which comes with KDE to get it going unter Tru64 using
> g++ 2.95.2:
>
> - ltconfig,v
>fixed -expect_unresolved stuff.
> - ltmain.sh,v
>fix for the problem that
Christopher Knight wrote:
>
> Hi Ossama,
>
> Unfortunately we do need dlopen and dlpreopen support. We have a C++ core that
> dlopens a bunch of C++ .so modules. One main reason we switched from Imake to
> Automake is to allow us to use the dlpreopen functionality without rolling
> our own :( We
Hi!
I would like to use -Bsymbolic for some of our libraries
to reduce the library size and the memory usage of the
processes linking to it (I'm still not sure why it does
that, but the numbers speak :)
The problem with this is that the linker needs for -Bsymbolic
to work all libraries passed. U
Thomas Tanner wrote:
>
> On 19-Feb-2000 Stephan Kulow wrote:
> >> I'm working on a fix.
> >> My first experimental patch (an ugly hack :( is attached.
> >> It's doesn't support the -la -lb -la case yet.
> > It doesn't work with sta
Thomas Tanner wrote:
>
> On 11-Feb-2000 Stephan Kulow wrote:
> > mkdir .libs
> > mkdir .libs
> > mkdir: Failed to make directory ".libs"; File exists
> > ../libtool: test: argument expected
> > make[2]: *** [ksconfig.lo] Error 1
> > make[2]:
Thomas Tanner wrote:
>
> On 14-Feb-2000 Stephan Kulow wrote:
> > Yes. I cleaned up KDE's situation a bit by now in removing LDFLAGS
> > that weren't strictly necessary but it's still a pain. I think, the
> > ILD should
> > 1) remove doubled -L ca
Alexandre Oliva wrote:
>
>
> In any case, it might be possible, even though extremely unlikely and
> of very bad taste, that the symbols of liba that are pulled by libx
> depend on libb. In this case, omitting the first occurrence of -la
> would cause the symbols in libb to not be resolved.
>
Alexandre Oliva wrote:
>
> On Feb 15, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
>
> > Alexandre Oliva wrote:
> >>
> >> On Feb 14, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
> >>
> >> > Alexandre Oliva wrote:
> &
Alexandre Oliva wrote:
>
> On Feb 14, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
>
> > Alexandre Oliva wrote:
> >>
> >> On Feb 14, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
> >>
> >> > 2) remove doubled base libraries to
Alexandre Oliva wrote:
>
> On Feb 14, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
>
> > 2) remove doubled base libraries to libraries.
>
> This can't be done in general. It has already been debated to death
> in this mailing list. Please search the
Ossama Othman wrote:
>
> Hi Stephan,
>
> Here's an update on the ILD line being too long in the multi-language
> branch.
>
> The changes I checked in to the multi-language branch a few days ago
> improves the situation for the multi-language branch adding the
> inter-library dependencies extrac
The Hermit Hacker wrote:
>
> I have a program that has a .h file that is generated by running a script,
> where that .h file needs to be generated before everything is compiled ...
>
> Reading through the info docs, I found the section on all-local being
> added to Makefile.am, etc, but when I r
27 matches
Mail list logo
