2 host, the compiler copies
its library DLLs to the `bin` directory. However, in the case of a multilib
configuration, both 32-bit and 64-bit libraries end up in the same `bin`
directory, leading to conflicts where 64-bit DLLs are overridden by their
32-bit counterparts.
This patch addresses the
mpiler copies
its library DLLs to the `bin` directory. However, in the case of a multilib
configuration, both 32-bit and 64-bit libraries end up in the same `bin`
directory, leading to conflicts where 64-bit DLLs are overridden by their
32-bit counterparts.
This patch addresses the issue by adj
ectory. However, in the case of a multilib
configuration, both 32-bit and 64-bit libraries end up in the same `bin`
directory, leading to conflicts where 64-bit DLLs are overridden by their
32-bit counterparts.
This patch addresses the issue by adjusting the installation path for the
lib
is to use --build=x86_64-gnu-linux --host=i386-gnu-linux
with CC and CXX set to 'gcc|g++ -m32', i.e. multilib .
The libtool regression suite fail in test case :
25: duplicate convenience archive names FAILED
(duplicate_conv.at:83)
From testsuite.log:
.../libtool
++ -m32', i.e. multilib .
The libtool regression suite fail in test case :
25: duplicate convenience archive names FAILED
(duplicate_conv.at:83)
From testsuite.log:
.../libtool-2.4.2/tests/duplicate_conv.at:83: $LIBTOOL --mode=link
--tag=CC $CC $CFLAGS $LDFLAGS -o cee.$OBJEXT
Hello All,
I wonder how to build and test on a 64 bit platform a 32 bit libtool
version.
First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux with
CC and CXX set to 'gcc|g++ -m32', i.e. multilib .
The libtool regression suite fail in test case :
25: duplicate convenience
Hi Peter,
* Peter O'Gorman wrote on Thu, Jan 31, 2008 at 08:00:59AM CET:
I installed amd64 debian in a VM and with this patch I get:
/usr/lib/gcc/x86_64-linux/gnu/4.1.2 /usr/lib /lib
I do not know if it is best to leave in the symlink and the original dir
( i.e. do cd $dir pwd as well as
Ralf Wildenhues wrote:
I have not yet tried to understand the logic of the patch.
Sorry. I have dropped it. libstdc++ should still be found because of the
compiler_search_path changes.
Peter
--
Peter O'Gorman
http://pogma.com
paths and adds them to
sys_lib_search_path_spec. This causes issues, some of which are because
of gcc's .la files containing the build directory, but not limited to
that. It is most likely to cause problems when building for a multilib
target.
I am proposing this as a patch. I do not really like
, with both 64bit mode (./configure) and 32bit mode
(./configure CPPFLAGS=-m32 LDFLAGS=-m32). For Debian, the latter
is wrong, /usr/lib64 is a symlink to /usr/lib. Before the patch,
both modes looked better.
A general question: do all these changes to multilib path searching
not also increase the set
; then
+_lt_dir=`ls -ld [$]1 | ${SED} 's/.* - //'`
+ else
+_lt_dir=[$]1
+ fi
+ lt_func_print_dir_resolving_links_result=`cd $_lt_dir pwd`
+fi
+}
+
# Ok, now we have the path, separated by spaces, we can step through it
# and add multilib dir if necessary.
lt_tmp_lt_search_path_spec
* Peter O'Gorman wrote on Thu, Jan 31, 2008 at 08:00:59AM CET:
I do not know if it is best to leave in the symlink and the original dir
( i.e. do cd $dir pwd as well as cd $dir pwd -P), which on debian
would give something like:
/usr/lib/gcc/x86_64-linux/gnu/4.1.2 /usr/lib64 /usr/lib /lib64
Hi,
Multilib is still broken in head and the stable branch.
This patch (branch-1-5) fixes it.
There has got to be a better way!
Ideas?
Peter
--
Peter O'Gorman
http://pogma.com
Index: libtool.m4
===
RCS file: /sources/libtool
,
and all recent releases of XEmacs.
[EMAIL PROTECTED]
+When building on some linux systems for multilib targets
[EMAIL PROTECTED] sometimes guesses the wrong paths that the linker
+and dynamic linker search by default. If this occurs, you may override
+libtool's guesses at @command{configure} time
,
and all recent releases of XEmacs.
[EMAIL PROTECTED]
+When building on some linux systems for multilib targets
[EMAIL PROTECTED] sometimes guesses the wrong paths that the linker
+and dynamic linker search by default. If this occurs, you may override
+libtool's guesses at @command{configure} time
Hi Peter,
* Peter O'Gorman wrote on Mon, Jan 21, 2008 at 07:29:08PM CET:
I give up on trying to find fancy ways to set the paths, ok to apply
this to branch-1-5 (and similar for HEAD)?
I suppose, yes, but I guess some mention in the documentation would not
be bad.
Thank you,
Ralf
Ralf Wildenhues wrote:
Hi Peter,
* Peter O'Gorman wrote on Wed, Sep 05, 2007 at 08:02:59AM CEST:
Proposed patches for branch-1-5 and HEAD.
Okay to apply?
Not quite, I'm afraid. First, please put $CPPFLAGS before $LDFLAGS, for
consistency.
We should consider just making this whole
Hi Peter,
* Peter O'Gorman wrote on Mon, Jan 21, 2008 at 07:29:08PM CET:
I give up on trying to find fancy ways to set the paths, ok to apply
this to branch-1-5 (and similar for HEAD)?
I suppose, yes, but I guess some mention in the documentation would not
be bad.
Thank you,
Ralf
Proposed patches for branch-1-5 and HEAD.
Okay to apply?
Peter
2007-09-05 Peter O'Gorman [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER) [linux]: Try to set
the dynamic linker search path properly for multilib case.
Index: libtool.m4
2007-09-05 Peter O'Gorman [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER) [linux]: Try to set
the dynamic linker search path properly for multilib case.
On Thu, 2007-09-06 at 00:25 +0200, Ralf Wildenhues wrote:
Hi Ralf, thank you for testing!
Further, the indiscriminate use of ldd, or absolute file names in the
test of course prevents decent cross-compile results. (Not that this
is much of a regression, the problem existed before.)
Proposed patches for branch-1-5 and HEAD.
Okay to apply?
Peter
2007-09-05 Peter O'Gorman [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER) [linux]: Try to set
the dynamic linker search path properly for multilib case.
Index: libtool.m4
2007-09-05 Peter O'Gorman [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER) [linux]: Try to set
the dynamic linker search path properly for multilib case.
___
http://lists.gnu.org/mailman/listinfo/libtool
On Thu, 2007-09-06 at 00:25 +0200, Ralf Wildenhues wrote:
Hi Ralf, thank you for testing!
Further, the indiscriminate use of ldd, or absolute file names in the
test of course prevents decent cross-compile results. (Not that this
is much of a regression, the problem existed before.)
On Wednesday 22 August 2007, Peter O'Gorman wrote:
libsuff=`ldd conftest 2/dev/null | awk '/libc\.so/
{n=split([$]3,x,/); for (i=0; i n; i++) { if (x[[i]] == lib64) {print
64}}}'`
this test would still be subject to the environment of ldd ... in otherwords,
it is still possible to have ldd
On Wed, 2007-08-22 at 06:40 -0400, Mike Frysinger wrote:
On Wednesday 22 August 2007, Peter O'Gorman wrote:
libsuff=`ldd conftest 2/dev/null | awk '/libc\.so/
{n=split([$]3,x,/); for (i=0; i n; i++) { if (x[[i]] == lib64) {print
64}}}'`
this test would still be subject to the
On Wednesday 22 August 2007, Peter O'Gorman wrote:
On Wed, 2007-08-22 at 06:40 -0400, Mike Frysinger wrote:
On Wednesday 22 August 2007, Peter O'Gorman wrote:
libsuff=`ldd conftest 2/dev/null | awk '/libc\.so/
{n=split([$]3,x,/); for (i=0; i n; i++) { if (x[[i]] == lib64)
{print
Hi,
Albert pointed out to me yesterday that while, with 1.5.24 we now add
the correct directories to sys_lib_search_path_spec, they do not get
added to sys_lib_dlsearch_path_spec, resulting in libtool putting, for
example, /usr/lib64 in RPATH.
Red Hat have a patch for this, but it is specific to
Hi,
I'm on amd64, and want to build my package for both, x86 and amd64. so while
the latter works just fine, the first does not.
On AMD64, NVIDIA provides a /usr/lib{32,64}/libGL.la, but other graphics
vendors obviousely don't.
Below is an extract from my output from running make to build the
Hello Christian,
* Christian Parpart wrote on Fri, Feb 16, 2007 at 02:41:54PM CET:
I'm on amd64, and want to build my package for both, x86 and amd64. so while
the latter works just fine, the first does not.
Please try the 1.5.23b beta release due for release sometime this
weekend.
Cheers,
* Peter O'Gorman wrote on Sat, Oct 21, 2006 at 02:11:19PM CEST:
On Oct 21, 2006, at 8:52 PM, Ralf Wildenhues wrote:
Do you have better ideas?
No, the way I tested it was to run ./configure; make with CC set to
gcc -m32 and gcc -m64 on a few systems and look at
sys_lib_search_path_spec
:47:13 -
@@ -35,6 +35,7 @@
as BeOS.
* Initial support for the Sun compiler suite on GNU/Linux.
* Improved support for GNU/kFreeBSD and GNU/NetBSD.
+* Search paths with GCC on multilib systems like x86_64 have been fixed.
* Bug fixes.
New in 1.9f: 2004-10-23; CVS version 1.9e, Libtool
Hi,
This is what I came up with to take -m64/-m32 into account when using gcc.
Okay?
Peter
Index: ChangeLog
2006-10-18 Peter O'Gorman [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER): Improve multilib
support.
Reported by Kate Minola [EMAIL PROTECTED
On Oct 19, 2006, at 1:13 AM, Bob Friesenhahn wrote:
On Wed, 18 Oct 2006, Peter O'Gorman wrote:
Hi,
This is what I came up with to take -m64/-m32 into account when
using gcc.
I am not able to spot a problem with it. Extensive testing will
prove if it works as expected. Hopefully this
Hello Michael,
* Michael Haubenwallner wrote on Wed, Sep 13, 2006 at 05:07:04PM CEST:
Based on recent thread on AC_LIBTOOL_SYS_DYNAMIC_LINKER:
I wonder why it is actually necessary for libtool to query system
library search dirs from gcc, because when gcc is used as linker, it
will know
Hi,
Based on recent thread on AC_LIBTOOL_SYS_DYNAMIC_LINKER:
I wonder why it is actually necessary for libtool to query system
library search dirs from gcc, because when gcc is used as linker, it
will know where to get system libs from.
Are there exceptions to this behaviour, which libtool has
Ralf Wildenhues wrote:
That is only half of the problem. If it were the only problem, then we
could just prepend all the lib64 paths on GNU/Linux, and the sparcv9
ones on Solaris. The other half is that libtool does not skip libraries
it finds there: deplibs_check_method is set to pass_all.
On Fri, 31 Mar 2006, Simon Stelling wrote:
Ralf Wildenhues wrote:
That is only half of the problem. If it were the only problem, then we
could just prepend all the lib64 paths on GNU/Linux, and the sparcv9
ones on Solaris. The other half is that libtool does not skip libraries
it finds
Bob Friesenhahn wrote:
Uhm, why is that a problem? If libtool did a check which ABI it's
actually
compiling/linking for, it could always prepend the appropriate path, no?
That sounds like a good plan. Unfortunately, libtool does not appear to
check ABIs while linking. Instead it uses
On Fri, 31 Mar 2006, Simon Stelling wrote:
Bob Friesenhahn wrote:
Uhm, why is that a problem? If libtool did a check which ABI it's
actually
compiling/linking for, it could always prepend the appropriate path, no?
That sounds like a good plan. Unfortunately, libtool does not appear to
Hi Simon, Bob,
Sorry for the delay.
* Bob Friesenhahn wrote on Sun, Mar 12, 2006 at 04:53:37PM CET:
On Sat, 11 Mar 2006, Simon Stelling wrote:
It seems like libtool has some problems on multilib-enabled systems.
Yes.
When libtool is given a -l argument is tries to find a matching libtool
On Sat, 11 Mar 2006, Simon Stelling wrote:
It seems like libtool has some problems on multilib-enabled systems.
When libtool is given a -l argument is tries to find a matching libtool
archive by searching through various paths:
for searchdir in '$newlib_search_path' '$lib_search_path
[ please forgive the webmailer messing up the lines ]
Peter O'Gorman writes:
I'm not really too knowledgable of the problem space. What are the
problems with multilib? Is it just that libtool searches the wrong
libdirs?
That's one of them.
Libtool aims out to do the same thing the linker
this which, as far as I can see, is
AC not current behavior.
Good points. (Fwiw I didn't make the patch...:)
Is the revised patch below any better?
-Jens
--- libtool-1.5.4/libtool.m4.multilib 2004-04-05 21:09:54.0 +0900
+++ libtool-1.5.4/libtool.m42004-04-05 22:00:20.0 +0900
On Mon, 2004-04-05 at 14:12, Jens Petersen wrote:
Albert, Thank you for looking at the patch, and sorry for taking
too long to follow up to your comments. (please see below)
AC You reset sys_lib_dlsearch_path_spec.
AC So, do you want to add to sys_lib_dlsearch_path_spec?
SJR == Scott James Remnant [EMAIL PROTECTED] writes:
SJR 2004-04-05 at 14:12, Jens Petersen wrote:
Is the revised patch below any better?
SJR This patch is still RedHat/Fedora specific with no
SJR check to make sure it is only running on that
SJR system.
Yep, that's
I have a general opensource packaging/build question that is sort of
related to libtool (I think) and was hoping someone could answer it
or provide me with a pointer.
For an opensource package that consists of one or more libraries and
that uses configure, automake, libtool, and the usual
Steve Ellcey [EMAIL PROTECTED] writes:
Should I just tell the user to do two builds,
with different options and different install directories?
For what it's worth, in GMP that's what we've done.
In principle there could be different libc functions and stuff in
different ABIs, so a fresh run
48 matches
Mail list logo
