> I have renamed the libtool --with-sysroot to --with-libtool-sysroot
> for experments to avoid the conflict
> and it worked well for me.
>
> See the patch here.
>
> http://git.openembedded.org/cgit.cgi/openembedded/tree/recipes/libtool/libtool-2.4/rename-with-sysroot.patch
>
> I guess thats not be
On 10/23/2010 10:01 AM, Ralf Wildenhues wrote:
Hi Paolo,
* Paolo Bonzini wrote on Sat, Oct 23, 2010 at 09:38:43AM CEST:
Also, libtool should probably ignore --with-sysroot if build==host;
native compilers are never build with a sysroot in practice.
OK, so this would mean there is no way
On 10/21/2010 10:23 PM, Khem Raj wrote:
> toolchain has two options when it comes to sysroot --with-sysroot and
> --with-build-sysroot I think libtool should
> also differentiate between two and set both to same if not explicitly
> set during configure time. I think libtool
> means to use build tim
> package1: ./configure
> package1: make install DESTDIR=/tmp/root1
>
> package2: ./configure
> package2: make install DESTDIR=/tmp/root2
>
> 1. No need to update existing builds, adding --with-sysroot to all
> configure statements is harder.
Hardly impossible though.
> 2. You can assume DESTDIR
On 09/27/2010 03:41 PM, Alon Bar-Lev wrote:
Thanks for the explanation!
On Sun, Sep 26, 2010 at 7:17 AM, Ralf Wildenhues wrote:
Also, why not take the value of the sysroot from the DESTDIR automake variable?
Because we know DESTDIR far too late, only at 'make install' time and
not yet at th
On 06/09/2010 04:46 PM, Gary V. Vaughan wrote:
Why so much cruft in ltmain.m4sh just to drive a different archiver? It
seems to me that this would be better and easier to maintain, test and extend
as a whole new script. Let's call it, $prefix/libexec/libtool/ar, build it
from $srcdir/libltdl/co
On 12/14/2009 07:25 PM, Adam Mercer wrote:
cd /us
On Mon, Dec 14, 2009 at 12:13, Paolo Bonzini wrote:
I only have this problem with Ubuntu 9.10, does anyone know what could
be causing this?
What is the output of autoreconf --version?
It reports itself as 2.64
Can you attach your
/usr
I only have this problem with Ubuntu 9.10, does anyone know what could
be causing this?
What is the output of autoreconf --version? Can you attach your
/usr/bin/autoreconf so that we can look for Canonical patches?
Thanks!
Paolo
___
http://list
Right. dlsym(RTLD_NEXT, "open") will give you the one that you shadowed;
this might not be the real symbol yet as there may be other wrappers
loaded, and it might not be the one from libc as applications are
allowed to provide their own definitions of symbols and have them take
precedence.
Tha
On 12/03/2009 08:20 AM, Ralf Wildenhues wrote:
We should probably change the code so that the override can be done
before AC_PROG_LIBTOOL, so that at least -DPIC is added consistently,
and that the compile test uses the right flag.
Using a "real" cache variable will do. I'll give it a shot.
P
On 10/11/2009 11:41 AM, Kent Boortz wrote:
(F) The linker, it should know about GLIBC_PRIVATE, and search for
non private occurrences first, then if not found do another scan
for private ones?
No, GLIBC_PRIVATE is not very different from ABC_XYZ from the linker's
point-of-view. :
On 07/24/2009 11:25 AM, Jan Engelhardt wrote:
Hi,
when one has a program that does something like
if(strcmp(argv[0], "gunzip") == 0)
uncompress();
else
compress();
and this program also uses a libtool library, then the - lets use this
example - just-built "gzip" file will be a
m4_define([m4_provided], [
m4_provide_if([AC_PROG_LIBTOOL], [], [
m4_provide_if([LT_INIT], [],
[m4_warn([syntax], [Libtool required by $1])])])])])
...
m4_provided([MY_MACRO_NAME])
I didn't count the number of closing brackets.
What is the m4_provide_if? I didn't find it in
The reason why I'm asking this is that I wrote some macros that rely on
Libtool's magic handling of -R and even though it's clearly stated in
the doc/comments/README that Libtool is mandatory, people keep running
in troubles because they didn't use Libtool, so I'd like to trigger an
error, so
In debian, libncurses.so is not installed unless libncurses-dev is
also installed. Therefore, programs should open libncurses.so.5
directly.
No. Ideally the installation script for your program would create a
symlink from a private directory for your program to the libncurses that
your pro
The only way I see that happen in a sane way is to have all three
libtool version numbers passed to a new lt_dlopenadvise API (CVS HEAD)
and have libltdl compute the soversion from there.
Yes, that's a good idea for the interface. But the implementation is no
less of a mess. First, as you p
In debian, libncurses.so is not installed unless libncurses-dev is also
installed. Therefore, programs should open libncurses.so.5 directly.
However, this is not possible with ltdl_openext. Would a patch be
accepted to extend ltdl_openext("libncurses.5") like this:
- of course, opening "lib
At a slight tangent; maybe m4sh could provide a shell function
calling macro
(off the top of my head):
Isn't this a bit heavyweight?
| It should be even with an integer return value. If you are at the
| end of a function (or in an if just before the end of the function, you
| got it) it is pos
I am using the attached macro as a backport of AC_LIBTOOL_TAGS to
libtool 1.5.
Paolo
# backported from libtool 1.6 by Paolo Bonzini
# When AC_LIBTOOL_TAGS is used, I redefine _LT_AC_TAGCONFIG
# to be more similar to the libtool 1.6 implementation, which
# uses an m4 loop and m4 case instead of a
> I seem to recall that libtool used to define something when compiling
> a shared library, but that this support was removed. Presumably this
> was because there was some other way to accomplish the same thing.
>
> Does anyone know of a way to get libtool to behave the way I need?
You may add som
Why make enable_shared and enable_static specific to a tag? Wouldn't
it be odd that you create shared libs for "C" programs and static for
"C++"? And, the --enable-shared and --enable-static options would have
to multiply (--enable-c-shared, --enable-cxx-shared, etc).
I'm using tags for something d
> Does this help?
> AC_LIBTOOL_TAGS([])
That's only in CVS (actually, I checked and it is not in 1.5, so it must be
in CVS).
I don't see it that bad that C is not a proper tag, actually.
It would also be good if enable_shared and enable_static became proper tag
variables instead of globals. BTW
I have just upgraded to libtool 1.5 (Debian's package which is taken out of
CVS) and here are my first experiences.
I'd like to make a custom tag so that, for a particular libtool library, PIC
code is also compiled with -fomit-frame-pointer (I really need the register
that is lost by the GOT code)
23 matches
Mail list logo
