Re: [PATCH] x86-64 and multilib
[moved from libtool-patches to libtool]
Albert, Thank you for looking at the patch, and sorry for taking
too long to follow up to your comments. (please see below)
> Index: libtool.m4
> ===
> RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v
> retrieving revision 1.37
> diff -u -r1.37 libtool.m4
> --- libtool.m45 Feb 2004 14:53:16 - 1.37
> +++ libtool.m46 Feb 2004 03:33:01 -
> @@ -1853,6 +1853,26 @@
># Append ld.so.conf contents to the search path
>if test -f /etc/ld.so.conf; then
> lt_ld_extra=`$SED -e 's/[:,\t]/ /g;s/=[^=]*$//;s/=[^= ]* / /g' /etc/ld.so.conf
> | tr '\n' ' '`
> sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
>fi
:
># people can always --disable-shared, the test was removed, and we
># assume the GNU/Linux dynamic linker is in use.
>dynamic_linker='GNU/Linux ld.so'
> +
> + # find out which ABI we are using
> + libsuff=
> + case "$host_cpu" in
> +x86_64*|s390x*|powerpc64*)
> + echo '[#]line __oline__ "configure"' > conftest.$ac_ext
> + if AC_TRY_EVAL(ac_compile); then
> +case `/usr/bin/file conftest.$ac_objext` in
> + *64-bit*)
> +libsuff=64
> +;;
> +esac
> + fi
> + rm -rf conftest*
> + ;;
> +*)
> + ;;
> + esac
> + sys_lib_dlsearch_path_spec="/lib${libsuff} /usr/lib${libsuff}"
> + sys_lib_search_path_spec="/lib${libsuff} /usr/lib${libsuff}
> /usr/local/lib${libsuff}"
>;;
> "AC" == Albert Chin <[EMAIL PROTECTED]> writes:
AC> You reset sys_lib_dlsearch_path_spec.
AC> So, do you want to add to sys_lib_dlsearch_path_spec?
AC> Also, do you want to set sys_lib_search_path_spec,
AC> sys_lib_dlsearch_path_spec for non x86_64 systems?
AC> The patch does 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
@@ -1441,10 +1441,27 @@
# before this can be enabled.
hardcode_into_libs=yes
+ # find out which ABI we are using
+ libsuff=
+ case "$host_cpu" in
+ x86_64*|s390x*|powerpc64*)
+echo '[#]line __oline__ "configure"' > conftest.$ac_ext
+if AC_TRY_EVAL(ac_compile); then
+ case `/usr/bin/file conftest.$ac_objext` in
+ *64-bit*)
+libsuff=64
+sys_lib_search_path_spec="/lib${libsuff} /usr/lib${libsuff}
/usr/local/lib${libsuff}"
+;;
+ esac
+fi
+rm -rf conftest*
+;;
+ esac
+
# Append ld.so.conf contents to the search path
if test -f /etc/ld.so.conf; then
lt_ld_extra=`$SED -e 's/[:,\t]/ /g;s/=[^=]*$//;s/=[^= ]* / /g' /etc/ld.so.conf |
tr '\n' ' '`
-sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
+sys_lib_dlsearch_path_spec="/lib${libsuff} /usr/lib${libsuff} $lt_ld_extra"
fi
# We used to test for /lib/ld.so.1 and disable shared libraries on
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [PATCH] x86-64 and multilib
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? > > AC> Also, do you want to set sys_lib_search_path_spec, > AC> sys_lib_dlsearch_path_spec for non x86_64 systems? > AC> The patch does 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? > This patch is still RedHat/Fedora specific with no check to make sure it is only running on that system. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
m4 files not found during make dist
Sorry for trivial question. I've got project that uses ltdl. I'm using libltdl as a convenience library. make succeeds and builds working binaries - everything is ok. However (on some systems) make dist fails in libltdl subdirectory, because it doesn't find required files ltdl.m4 and libtool.m4. These files can be copied from /usr/share/... directories, but I would like not to put them in CVS. Also, I wouldn't like to put cp /usr/share/... ./ commands in autogen.sh (because directories might be different on exotic systems). How do I fix that? -- Maciej Pietrzak ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [PATCH] x86-64 and multilib
> "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 why I sent it to the libtool list and not libtool-patches this time. :) Do you have some suggestion how to generalise it to other Linux OSs? Cheers, Jens ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: m4 files not found during make dist
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It depends... What does libtoolize --version say? On 5 Apr 2004, at 20:07, Maciej Pietrzak wrote: Sorry for trivial question. I've got project that uses ltdl. I'm using libltdl as a convenience library. make succeeds and builds working binaries - everything is ok. However (on some systems) make dist fails in libltdl subdirectory, because it doesn't find required files ltdl.m4 and libtool.m4. These files can be copied from /usr/share/... directories, but I would like not to put them in CVS. Also, I wouldn't like to put cp /usr/share/... ./ commands in autogen.sh (because directories might be different on exotic systems). How do I fix that? - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAcfW8FRMICSmD1gYRAj4aAKDDM/ymlwn/RFmoDbq/oX9pA4YMQACdHsko stD71ThdnyKvw9ahZs/mpNw= =6pm/ -END PGP SIGNATURE- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [MAD SCIENCE EXPERIMENT]: Replace some libtool functionality with handcoded C
On Dec 8, 2003, Steve Ellcey <[EMAIL PROTECTED]> wrote:
> I'm curious. I thought I knew shell scripting and the basics of
> automake but I don't know what 'fnord' is
set fnord [expansion]; shift
is a common idiom to ensure that the variable expansion doesn't start
with say -e, causing set to do something other than setting the
argument list.
>> From: Alexandre Oliva <[EMAIL PROTECTED]>
>>
>> LIBTOOL_BEGIN_COMPILE_CC = set fnord \
>>
>> LIBTOOL_END_COMPILE_CC = ; shift 1; \
>> { test -d $$dir"/$(libtool_libdir) || \
>> $(mkdir_p) "$$dir"/$(libtool_libdir); } && \
>> rm -f "$$lofile"T "$$lofile" "$$dir/$$ofile" \
>> "$$dir/$(libtool_libdir)/$$ofile" || : ; \
>> $(LIBTOOL_COMPILE_CC_PIC) -o "$$dir/$(libtool_libdir)/$$ofile" \
>> $${1+"$$@"} && \
>> $(LIBTOOL_COMPILE_CC_NONPIC) -o "$$dir/$$ofile" $${1+"$$@"} && \
>> { echo pic_object=$(LIBTOOL_PIC_OBJECT); \
>> echo non_pic_object=$(LIBTOOL_NONPIC_OBJECT); } > "$$lofile"T && \
>> mv "$$lofile"T "$$lofile"
> ___
> Libtool mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/libtool
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
