Re: [PATCH v2 01/12] ltmain.sh: Fix sysroot paths being encoded into RPATHs

2022-04-20 Thread Richard Purdie
On Wed, 2022-04-20 at 01:12 +0100, Sam James wrote:
> 
> > On 17 Apr 2022, at 05:55, Alex Ameen  wrote:
> > 
> > This was all green down the line on the test suite on multiple systems (
> > don't get too excited yet ) until I found bugs in the testsuite...
> > 
> > I see how this flew under the radar previously though - currently there are
> > no tests which attempt to check RPATH or RUNPATH entries. I'll definitely be
> > working on that... I'm going to be working out some M4 macros to abstract
> > some functions like `lt_read_pheader([BIN], [ENTRY])',
> > `lt_read_rpath([BIN])', and `lt_read_runpath([BIN])', so that those can be
> > abstracted for handling non-ELF binaries.
> > 
> > I'll make a test case to the effect of `readelf -d -W BIN|grep -v
> > "$sysroot/";', if you have any additional input on new test cases let me
> > know.
> > 
> > You also helped me catch some bad regex in the existing sysroot tests that
> > would cause them to never be run on a system which used '/' as their GCC
> > sysroot ( all of dpkg's  cross compilers seem to... ).
> 
> Nice! I've found a *lot* of things don't respect this case, actually.
> 
> > 
> > So a big thank you for helping to catch all of these places that the tool
> > can be improved.
> > 
> > Naturally now that test cases aren't skipped they're red, so once I sanity
> > check that they fail on the mainline branch I can move forward. I'm ~99%
> > sure this patch will have no effect on those results.
> > 
> > 
> 
> FWIW, given the comments on the main libtool ML, I at least am happy to drop
> this one for now, and revisit later. Richard might feel differently though.

I think this one is ok, it would be "ltmain.in: Don't encode RATHS which match
default linker paths" which is being questioned. We see a awful lot of it and I
don't think we need them but I can see the concern others are raising even if it
what I think should be a more unusual use case. It may be something that could
be configured ultimately?

> I like incremental progress so the more easy stuff in, the better, even if it
> means we have to come back to some of the harder ones.

Definitely agreed. I'd rather we make progress on the things we can agree on
that block on that.

Cheers,

Richard




Re: rpath stripping

2022-04-18 Thread Richard Purdie
On Mon, 2022-04-18 at 07:39 -0400, Carlos O'Donell wrote:
> On 4/17/22 10:06, Bob Friesenhahn wrote:
> > The libtool I was using (originating from Ubuntu Linux) stripped the
> > rpath (which was provided like '-Wl,rpath=/usr/lib') so I was unable
> > to embed an rpath in the libcurl I built so that applications linked
> > with that libcurl would find it.
> 
> I agree with our position.
> 
> The behaviour of stripping '-Wl,-rpath' is incorrect.
> 
> With new DT_RUNPATH semantics (DT_RPATH being deprecated and binutils having
> switched defaults), each shared object, including the binary, must correctly
> specify the search path for the immediate needed objects. Stripping this off
> will result in incorrectly built shared objects and binaries that don't
> operate correctly.
> 
> I'm curious what justification is given for this behaviour.

As I understand it the dynamic loader has a set of search paths it falls back to
(sys_lib_dlsearch_path in libtool). An RPATH or RUNPATH entry matching a system
loader path isn't usually of much use, it just takes up space.

I can imagine some cases where that might not be true such as linking with "-z
nodeflib" or some fairly convoluted setups but I suspect those would have other
issues too.

Cheers,

Richard





Submission process for libtool?

2022-03-31 Thread Richard Purdie
Hi,

It was great to see a libtool release, thanks for that!

I upgraded Yocto Project to it in time for our LTS release:

https://git.yoctoproject.org/poky/commit/?id=ff7b41573842a403c81f58bee41fc8163a9d7754

so far things seem reasonable, we've had a few minor issues but they're not
really libtool's fault or concern. One interesting quirk was that the shell
script optimisation changes made between 2.4.6 and 2.4.7 resulted in very long
(6,000+ character) pathnames being passed to the C library functions. This upset
our fakeroot emulation but we've fixed that to workaround the issue.

Yocto Project is carrying a few patches. I did clean them up and shared many of
them in October:

https://lists.gnu.org/archive/html/libtool-patches/2021-10/msg00012.html

Some are more important than others and there what I believe are good bug fixes
in there. My questions:

a) Is there a possibility these could be considered for merging?

b) Should I rebase and repost them? I'm happy to do it if it would help.

c) Am I using the right process for patch submission? I never did get a reply
despite asking publicly and privately. If I'm doing something wrong process wise
to submit them, I'd happily correct it.

Yocto Project is interesting as we can quickly test changes against the software
of a whole Linux stack across many architectures "quite quickly" (complete build
and tests in a few hours). I'm going to try and more closely track libtool
development so that we hopefully identify regressions from our perpective
quickly.

Thanks,

Richard








Re: new release?

2022-02-06 Thread Richard Purdie
On Sat, 2022-02-05 at 21:06 -0500, Mike Frysinger wrote:
> On 05 Feb 2022 15:15, Alex Ameen wrote:
> > This is a good question. I plan on making a new release this month.
> > 
> > When I first adopted the project I ambitiously thought I'd manage to 
> > create a new release after about a month; but the truth is when I 
> > started doing a deep dive into the internals there was a lot of history 
> > and complexity for me to unpack. Things that are easy to overlook like 
> > how change-logs get generated, quirks in the testing framework, and 
> > tracing down disparate areas to align documentation took quite a while 
> > to navigate.
> > 
> > The good news is that I think I've got the confidence to push a release 
> > soon. One area that I was reading up on this weekend was whether the 
> > "alpha"/private releases of `libtool' might be appropriate, or whether I 
> > should just push a release immediately. I'll admit I am leaning towards 
> > just making a release to avoid the entire alpha process for the time being.
> 
> i wouldn't sweat it too much.  the next release of libtool will be 2.6, and
> you can note its state in the announcement/NEWS.  distros will give it a run
> to find regressions, and as fixes are merged, just do 2.6.1, 2.6.2, etc...
> 

I'd like to second that. Getting a release out would be great even if it isn't
perfect, then go from there.

I know there are some Yocto Project patches for issues we've collected from
across the embedded ecosystem over the last few years that I rebased and posted
in the hope they could be merged. I'd rather we got to those in due course and
had a release though! :)

Cheers,

Richard






Re: New libtool maintainer

2021-11-21 Thread Richard Purdie
On Sun, 2021-11-21 at 13:14 -0600, Alex Ameen wrote:
> I just took a look at those. Good catches on the typos, I probably would 
> not have noticed them just reading the script myself. Same thing with 
> the M4 `[]' quoting issue ( classic pitfall ). I'll get these merged ASAP.
> 
> For the non-Linux patches I can merge them, but I don't have personally 
> have OSX, powerpc, or Solaris boxes, and while I do have a Windows 
> partition I don't currently have it set up to run these kinds of tests. 
> Nonetheless I can merge these - if you have access to any of those 
> platforms let me know if you would be open to running `make check' and 
> posting the logs so I can sanity check the new behavior.
> 
> Thank you so much for bringing these to my attention. There's a long 
> list of old patches and mailing list archives and as a practical matter 
> it's hard to know which of them are still relevant - so I appreciate 
> your help.

I did recently post the better bits of the OpenEmbedded/Yocto Project patchset
for libtool:

https://lists.gnu.org/archive/html/libtool-patches/2021-10/msg00012.html

Those are at up to date and in regular use in OE/YP which is widely used for
cross compiling for Linux/mingw and others. We tend to find sysroot and cross
compile issues in particular and we also find reproducibility and parallel make
race issues.

If you have any questions or concerns on any of those I'm happy to try and help.

Cheers,

Richard






[PATCH 01/12] ltmain.in: Handle trailing slashes on install commands correctly

2021-10-25 Thread Richard Purdie
A command like:

libtool --mode=install /usr/bin/install -c gck-roots-store-standalone.la 
'/image/usr/lib/gnome-keyring/standalone/'

where the path ends with a trailing slash currently fails. This occurs in
software like gnome-keyring or pulseaudio and is because the comparision
code doesn't see the paths as equal. Strip both paths to ensure this works
reliably.

Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 96b37003..3d5dcd0a 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -2378,8 +2378,14 @@ func_mode_install ()
func_append dir "$objdir"
 
if test -n "$relink_command"; then
+ # Strip any trailing slash from the destination.
+ func_stripname '' '/' "$libdir"
+ destlibdir=$func_stripname_result
+ func_stripname '' '/' "$destdir"
+ s_destdir=$func_stripname_result
+
  # Determine the prefix the user has applied to our future dir.
- inst_prefix_dir=`$ECHO "$destdir" | $SED -e "s%$libdir\$%%"`
+ inst_prefix_dir=`$ECHO "X$s_destdir" | $Xsed -e "s%$destlibdir\$%%"`
 
  # Don't allow the user to place us outside of our expected
  # location b/c this prevents finding dependent libraries that
-- 
2.25.1




[PATCH 04/12] ltmain.sh: Fix sysroot paths being encoded into RPATHs

2021-10-25 Thread Richard Purdie
There is a bug where RPATHs could end up containing sysroot values when
cross compiling which is obviously incorrect. Strip out sysroot components
from libdir when building RPATH values to avoid this.

Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 2c994612..96238350 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -7654,9 +7654,11 @@ EOF
  test relink = "$opt_mode" || rpath=$compile_rpath$rpath
  for libdir in $rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
-   func_replace_sysroot "$libdir"
-   libdir=$func_replace_sysroot_result
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir
else
@@ -8386,6 +8388,10 @@ EOF
   hardcode_libdirs=
   for libdir in $compile_rpath $finalize_rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir
@@ -8437,6 +8443,10 @@ EOF
   hardcode_libdirs=
   for libdir in $finalize_rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir
-- 
2.25.1




[PATCH 09/12] Makefile.am: make sure autoheader run before autoconf

2021-10-25 Thread Richard Purdie
From: Mingli Yu 

autoheader will update ../libtool-2.4.6/libltdl/config-h.in which
autoconf needs, so there comes a race sometimes as below:
 | configure.ac:45: error: required file 'config-h.in' not found
 | touch '../libtool-2.4.6/libltdl/config-h.in'

So make sure autoheader run before autoconf to avoid this race.

Signed-off-by: Mingli Yu 
Signed-off-by: Richard Purdie 
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 6b546092..84795d87 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -370,7 +370,7 @@ lt_configure_deps = $(lt_aclocal_m4) $(lt_aclocal_m4_deps)
 $(lt_aclocal_m4): $(lt_aclocal_m4_deps)
$(AM_V_GEN)cd '$(srcdir)/$(ltdl_dir)' && $(ACLOCAL) -I ../m4
 
-$(lt_configure): $(lt_configure_deps)
+$(lt_configure): $(lt_configure_deps) $(lt_config_h_in)
$(AM_V_GEN)cd '$(srcdir)/$(ltdl_dir)' && $(AUTOCONF)
 
 $(lt_config_h_in): $(lt_configure_deps)
-- 
2.25.1




[PATCH 06/12] libtool.m4: Handle "/" as a sysroot correctly

2021-10-25 Thread Richard Purdie
Update libtool.m4 to resolve a problem with lt_sysroot not being properly
updated if the option '--with[-libtool]-sysroot' is not provided when
running the 'configure' script for a package so that "/" as a sysroot
is handled correctly by libtool.

Signed-off-by: Richard Purdie 
---
 m4/libtool.m4 | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index de2f1ebf..180dd9d1 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1256,16 +1256,20 @@ dnl lt_sysroot will always be passed unquoted.  We 
quote it here
 dnl in case the user passed a directory name.
 lt_sysroot=
 case $with_libtool_sysroot in #(
- yes)
+ no)
if test yes = "$GCC"; then
  lt_sysroot=`$CC --print-sysroot 2>/dev/null`
+ # Treat "/" the same a an unset sysroot.
+ if test "$lt_sysroot" = /; then
+   lt_sysroot=
+ fi
fi
;; #(
+ yes|''|/)
+   ;; #(
  /*)
lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
;; #(
- no|'')
-   ;; #(
  *)
AC_MSG_RESULT([$with_libtool_sysroot])
AC_MSG_ERROR([The sysroot must be an absolute path.])
-- 
2.25.1




[PATCH 05/12] ltmain.in: Don't encode RATHS which match default linker paths

2021-10-25 Thread Richard Purdie
We don't want to add RPATHS which match default linker search paths, they're
a waste of space. This patch filters libtools list of paths to encoode and
removes the ones we don't need.

Libtool may be passed link paths of the form "/usr/lib/../lib" so normalize
the paths before comparision.

Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 34 --
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 96238350..6fb58ed2 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -7672,8 +7672,16 @@ EOF
  esac
fi
  else
-   eval flag=\"$hardcode_libdir_flag_spec\"
-   func_append dep_rpath " $flag"
+# We only want to hardcode in an rpath if it isn't in the
+# default dlsearch path.
+func_normal_abspath "$libdir"
+libdir_norm=$func_normal_abspath_result
+   case " $sys_lib_dlsearch_path " in
+   *" $libdir_norm "*) ;;
+   *) eval flag=\"$hardcode_libdir_flag_spec\"
+   func_append dep_rpath " $flag"
+   ;;
+   esac
  fi
elif test -n "$runpath_var"; then
  case "$perm_rpath " in
@@ -8406,8 +8414,16 @@ EOF
  esac
fi
  else
-   eval flag=\"$hardcode_libdir_flag_spec\"
-   func_append rpath " $flag"
+# We only want to hardcode in an rpath if it isn't in the
+# default dlsearch path.
+func_normal_abspath "$libdir"
+libdir_norm=$func_normal_abspath_result
+   case " $sys_lib_dlsearch_path " in
+   *" $libdir_norm "*) ;;
+   *) eval flag=\"$hardcode_libdir_flag_spec\"
+   rpath+=" $flag"
+   ;;
+   esac
  fi
elif test -n "$runpath_var"; then
  case "$perm_rpath " in
@@ -8461,8 +8477,14 @@ EOF
  esac
fi
  else
-   eval flag=\"$hardcode_libdir_flag_spec\"
-   func_append rpath " $flag"
+# We only want to hardcode in an rpath if it isn't in the
+# default dlsearch path.
+   case " $sys_lib_dlsearch_path " in
+   *" $libdir "*) ;;
+   *) eval flag=\"$hardcode_libdir_flag_spec\"
+   func_append rpath " $flag"
+   ;;
+   esac
  fi
elif test -n "$runpath_var"; then
  case "$finalize_perm_rpath " in
-- 
2.25.1




[PATCH 03/12] ltmain.in: Add missing sysroot to library path

2021-10-25 Thread Richard Purdie
From: Khem Raj 

When using a sysroot we should append it to libdir, which is helpful in
cross builds as the system is staged in the sysroot. For normal builds,
i.e. when lt_sysroot is not set, it will still behave the same and add
-L/usr/lib to the relink command.

Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 3d5dcd0a..2c994612 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -6475,7 +6475,7 @@ func_mode_link ()
  fi
else
  # We cannot seem to hardcode it, guess we'll fake it.
- add_dir=-L$libdir
+ add_dir="-L$lt_sysroot$libdir"
  # Try looking first in the location we're being installed to.
  if test -n "$inst_prefix_dir"; then
case $libdir in
-- 
2.25.1




[PATCH 10/12] Makefile.am: make sure autoheader run before automake

2021-10-25 Thread Richard Purdie
From: Mingli Yu 

When use automake to generate Makefile.in from Makefile.am, there
comes below race:
 | configure.ac:45: error: required file 'config-h.in' not found

It is because the file config-h.in in updating process by autoheader,
so make automake run after autoheader to avoid the above race.

Signed-off-by: Mingli Yu 
Signed-off-by: Richard Purdie 
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 84795d87..8c9949ed 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -333,7 +333,7 @@ EXTRA_DIST += $(lt_aclocal_m4) \
  $(lt_obsolete_m4) \
  $(stamp_mk)
 
-$(lt_Makefile_in): $(lt_Makefile_am) $(lt_aclocal_m4)
+$(lt_Makefile_in): $(lt_Makefile_am) $(lt_aclocal_m4) $(lt_config_h_in)
$(AM_V_GEN)cd '$(srcdir)/$(ltdl_dir)' && $(AUTOMAKE) Makefile
 
 # Don't let unused scripts leak into the libltdl Makefile
-- 
2.25.1




[PATCH 11/12] ltmain.in: Handle prefix-map compiler options correctly

2021-10-25 Thread Richard Purdie
If lto is enabled, we need the prefix-map variables to be passed to the linker.
Add these to the list of options libtool passes through.

Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 606f17be..7dc2e897 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5392,10 +5392,11 @@ func_mode_link ()
   # -stdlib=*select c++ std lib with clang
   # -fsanitize=* Clang/GCC memory and address sanitizer
   # -fuse-ld=*   Linker select flags for GCC
+  # -f*-prefix-map*  needed for lto linking
   -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
   
-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \
   
-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
-  -specs=*|-fsanitize=*|-fuse-ld=*)
+  -specs=*|-fsanitize=*|-fuse-ld=*|-f*-prefix-map*)
 func_quote_arg pretty "$arg"
arg=$func_quote_arg_result
 func_append compile_command " $arg"
-- 
2.25.1




[PATCH 07/12] libtool: Fix support for NIOS2 processor

2021-10-25 Thread Richard Purdie
From: Marek Vasut 

The name of the system contains the string "nios2". This string
is caught by the some of the greedy checks for OS/2 in libtool,
in particular the *os2* branches of switch statements match for
the nios2 string, which results in incorrect behavior of libtool.

This patch adds an explicit check for *nios2* before the *os2*
checks to prevent the OS/2 check incorrectly trapping the nios2
as well.

Signed-off-by: Marek Vasut 
Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 20 
 1 file changed, 20 insertions(+)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 6fb58ed2..606f17be 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -519,6 +519,12 @@ libtool_validate_options ()
 test : = "$debug_cmd" || func_append preserve_args " --debug"
 
 case $host in
+  # For NIOS2, we want to make sure that it's not caught by the
+  # more general OS/2 check below. Otherwise, NIOS2 is the same
+  # as the default option.
+  *nios2*)
+opt_duplicate_compiler_generated_deps=$opt_preserve_dup_deps
+;;
   # Solaris2 added to fix 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16452
   # see also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59788
   *cygwin* | *mingw* | *pw32* | *cegcc* | *solaris2* | *os2*)
@@ -6246,6 +6252,15 @@ func_mode_link ()
if test -n "$library_names" &&
   { test no = "$use_static_libs" || test -z "$old_library"; }; then
  case $host in
+ *nios2*)
+   # For NIOS2, we want to make sure that it's not caught by the
+   # more general OS/2 check below. Otherwise, NIOS2 is the same
+   # as the default option.
+   if test no = "$installed"; then
+ func_append notinst_deplibs " $lib"
+ need_relink=yes
+   fi
+   ;;
  *cygwin* | *mingw* | *cegcc* | *os2*)
  # No point in relinking DLLs because paths are not encoded
  func_append notinst_deplibs " $lib"
@@ -6316,6 +6331,11 @@ func_mode_link ()
elif test -n "$soname_spec"; then
  # bleh windows
  case $host in
+ *nios2*)
+   # For NIOS2, we want to make sure that it's not caught by the
+   # more general OS/2 check below. Otherwise, NIOS2 is the same
+   # as the default option.
+   ;;
  *cygwin* | mingw* | *cegcc* | *os2*)
func_arith $current - $age
major=$func_arith_result
-- 
2.25.1




[PATCH 08/12] libtool: Check for static libs for internal compiler libraries

2021-10-25 Thread Richard Purdie
From: Khem Raj 

Libtool checks only for libraries linked as -l* when trying to
find internal compiler libraries. Clang, however uses the absolute
path to link its internal libraries e.g. compiler_rt. This patch
handles clang's statically linked libraries when finding internal
compiler libraries.

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie 
---
 m4/libtool.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 180dd9d1..022c1292 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -7560,7 +7560,7 @@ if AC_TRY_EVAL(ac_compile); then
   for p in `eval "$output_verbose_link_cmd"`; do
 case $prev$p in
 
--L* | -R* | -l*)
+-L* | -R* | -l* | */libclang_rt.*.a)
# Some compilers place space between "-{L,R}" and the path.
# Remove the space.
if test x-L = "$p" ||
-- 
2.25.1




[PATCH 12/12] libtool.m4: For reproducibility stop encoding hostname in libtool script

2021-10-25 Thread Richard Purdie
For reproducibilty, stop encoding the hostname into the libtool script, this 
isn't
really adding much to debugging and most distros are carrying such a patch now 
as
reproducibility is important.

Signed-off-by: Richard Purdie 
---
 m4/libtool.m4 | 1 -
 1 file changed, 1 deletion(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 022c1292..1a8a2998 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -728,7 +728,6 @@ _LT_CONFIG_SAVE_COMMANDS([
 cat <<_LT_EOF >> "$cfgfile"
 #! $SHELL
 # Generated automatically by $as_me ($PACKAGE) $VERSION
-# Libtool was configured on host `(hostname || uname -n) 2>/dev/null | sed 1q`:
 # NOTE: Changes made to this file will be lost: look at ltmain.sh.
 
 # Provide generalized library-building support services.
-- 
2.25.1




[PATCH 02/12] libtool.m4: Rename the --with-sysroot option to avoid conflict with gcc/binutils

2021-10-25 Thread Richard Purdie
From: Khem Raj 

This patch renames the --with-sysroot option to --with-libtool-sysroot
to avoid namespace conflict with binutils, gcc and other toolchain
components since these componets also add that option to configure
and this becomes confusing and conflicting otherwise.

Signed-off-by: Richard Purdie 
---
 m4/libtool.m4| 12 ++--
 tests/sysroot.at |  6 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index f2d1f398..de2f1ebf 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1246,28 +1246,28 @@ _LT_DECL([], [ECHO], [1], [An echo program that 
protects backslashes])
 # 
 AC_DEFUN([_LT_WITH_SYSROOT],
 [AC_MSG_CHECKING([for sysroot])
-AC_ARG_WITH([sysroot],
-[AS_HELP_STRING([--with-sysroot@<:@=DIR@:>@],
+AC_ARG_WITH([libtool-sysroot],
+[AS_HELP_STRING([--with-libtool-sysroot@<:@=DIR@:>@],
   [Search for dependent libraries within DIR (or the compiler's sysroot
if not specified).])],
-[], [with_sysroot=no])
+[], [with_libtool_sysroot=no])
 
 dnl lt_sysroot will always be passed unquoted.  We quote it here
 dnl in case the user passed a directory name.
 lt_sysroot=
-case $with_sysroot in #(
+case $with_libtool_sysroot in #(
  yes)
if test yes = "$GCC"; then
  lt_sysroot=`$CC --print-sysroot 2>/dev/null`
fi
;; #(
  /*)
-   lt_sysroot=`echo "$with_sysroot" | sed -e "$sed_quote_subst"`
+   lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
;; #(
  no|'')
;; #(
  *)
-   AC_MSG_RESULT([$with_sysroot])
+   AC_MSG_RESULT([$with_libtool_sysroot])
AC_MSG_ERROR([The sysroot must be an absolute path.])
;;
 esac
diff --git a/tests/sysroot.at b/tests/sysroot.at
index 05faa13d..7a1f9567 100644
--- a/tests/sysroot.at
+++ b/tests/sysroot.at
@@ -64,7 +64,7 @@ while read file; do
 done])
 
 LDFLAGS="$LDFLAGS --sysroot=$sysroot -no-undefined"
-configure_options="$configure_options --with-sysroot=$sysroot --prefix=$prefix"
+configure_options="$configure_options --with-libtool-sysroot=$sysroot 
--prefix=$prefix"
 
 #???
 if test PATH = "$shlibpath_var"; then
@@ -114,7 +114,7 @@ AM_INIT_AUTOMAKE([foreign])
 AC_PROG_CC
 AC_CONFIG_SRCDIR([lib2.c])
 LT_INIT
-sysroot=$with_sysroot
+sysroot=$with_libtool_sysroot
 AC_SUBST([sysroot])
 AC_OUTPUT(Makefile)
 ]])
@@ -155,7 +155,7 @@ AM_INIT_AUTOMAKE([foreign])
 AC_PROG_CC
 AC_CONFIG_SRCDIR([prog.c])
 LT_INIT
-sysroot=$with_sysroot
+sysroot=$with_libtool_sysroot
 AC_SUBST([sysroot])
 AC_OUTPUT(Makefile)
 ]])
-- 
2.25.1




[PATCH 00/12] Yocto Project libtool patch queue

2021-10-25 Thread Richard Purdie
Hi,

I saw comments about a possible pending release and decided to take the 
opportunity to send out the bulk of Yocto Project's patch queue
for libtool. We use it in a cross compiling environment and make
extensive use of the sysroot support in the toolchain so most of our
issues are in that area but there are also some reproducubility and
reduction of unnecessary rpaths tweaks here.

We've been using these patches for many years in some cases so it
would be create to reduce our patchset and share the fixes with others.

Some have been on the libtool mailing lists before but I thought it
simpler to send the set out for review together as a set.

Cheers,

Richard

Khem Raj (3):
  libtool.m4: Rename the --with-sysroot option to avoid conflict with
gcc/binutils
  ltmain.in: Add missing sysroot to library path
  libtool: Check for static libs for internal compiler libraries

Marek Vasut (1):
  libtool: Fix support for NIOS2 processor

Mingli Yu (2):
  Makefile.am: make sure autoheader run before autoconf
  Makefile.am: make sure autoheader run before automake

Richard Purdie (6):
  ltmain.in: Handle trailing slashes on install commands correctly
  ltmain.sh: Fix sysroot paths being encoded into RPATHs
  ltmain.in: Don't encode RATHS which match default linker paths
  libtool.m4: Handle "/" as a sysroot correctly
  ltmain.in: Handle prefix-map compiler options correctly
  libtool.m4: For reproducibility stop encoding hostname in libtool
script

 Makefile.am |  4 +--
 build-aux/ltmain.in | 81 +++--
 m4/libtool.m4   | 25 --
 tests/sysroot.at|  6 ++--
 4 files changed, 89 insertions(+), 27 deletions(-)

-- 
2.25.1




Re: transitive shared library dependencies and installation

2020-01-03 Thread Richard Purdie
On Thu, 2020-01-02 at 16:24 -0600, Bob Friesenhahn wrote:
> On Thu, 2 Jan 2020, wf...@niif.hu wrote:
> > > If Libtool were to depend on non-portable features, [...] then it
> > > could not longer be described as a portability tool.
> > 
> > In my understanding, Libtool is a portability shim, providing a
> > regular
> > interface for developers across systems with wildly varying
> > features.
> > It already uses non-portable features, just different ones on
> > different
> > architectures.  I don't say it should use -rpath-link generally, I
> > only
> > suggested that it might be an efficient solution on systems
> > supporting
> > it.  But I expect all systems supporting shared objects to allow
> > using
> > and installing them some way, irrespective of their
> > interdependencies.
> > Am I overly naive?
> 
> Certainly, libtool could use -rpath-link where it is supported but 
> libtool provides a common feature set and if it is only possible to 
> support a feature where -rpath-link is available, then offering the 
> feature would defeat the purpose of being a portability tool.
> 
> Sometimes it is better to force the using software to conform to the 
> limitations.
> 
> Libtool must also work for static linking.  It seems to me that your 
> issue also impacts static linking.

I think the challenge that libtool has here is that many of these older
systems that libtool supports aren't so prevalent anymore.

I work on the Yocto Project where we do a ton of cross compiling and
have to work with libtool but its mostly Linux with a small amount of
mingw/baremetal/darwin bits.

We have a number of libtool patches to sort cross compile issues which
really need discussion with upstream libtool. With the lack of
releases, our incentive to do that diminishes :(.

By reducing everything to the lowest common denominator, it means
libtool struggles to take advantage of any new linker technology too.

Finding new maintainers with the amount of knowledge of weird older
systems needed is going to be a struggle which only gets worse over
time :(

I do worry about the future here as libtool is a key part of the
autotools fabric but its most likely to be wholesale replaced given how
things are trending.

Cheers,

Richard






Re: Trailing slash in directory spec confuses libtool

2016-08-12 Thread Richard Purdie
On Fri, 2016-08-12 at 22:06 +0200, Jan Engelhardt wrote:
> Given certain circumstances, libtool 2.4.2 fails to install a
> library. 
> (a) The target directory spec contains a trailing slash
> (b) The library to install is linking to another just-built one in a 
> different path.

FWIW we have this patch:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/libtool/libtool/trailingslash.patch

which seems to help. We've never been able to clean it up enough to
submit upstream or have a reliable test case for it though :(

Cheers,

Richard

[patch follows below]

A command like /bin/sh ../../i586-poky-linux-libtool   --mode=install 
/usr/bin/install -c   gck-roots-store-standalone.la 
'/media/data1/builds/poky1/tmp/work/core2-poky-linux/gnome-keyring-2.26.1-r1/image/usr/lib/gnome-keyring/standalone/'
 fails (e.g. gnome-keyring or pulseaudio)

This is because libdir has a trailing slash which breaks the comparison.

RP 2/1/10

Merged a patch received from Gary Thomas <g...@mlbassoc.com>

Date: 2010/07/12
Nitin A Kamble <nitin.a.kam...@intel.com>

Updated by: Robert Yang <liezhi.y...@windriver.com>

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -2356,8 +2356,15 @@ func_mode_install ()
func_append dir "$objdir"
 
if test -n "$relink_command"; then
+  # Strip any trailing slash from the destination.
+  func_stripname '' '/' "$libdir"
+  destlibdir=$func_stripname_result
+
+  func_stripname '' '/' "$destdir"
+  s_destdir=$func_stripname_result
+
  # Determine the prefix the user has applied to our future dir.
- inst_prefix_dir=`$ECHO "$destdir" | $SED -e "s%$libdir\$%%"`
+ inst_prefix_dir=`$ECHO "X$s_destdir" | $Xsed -e "s%$destlibdir\$%%"`
 
  # Don't allow the user to place us outside of our expected
  # location b/c this prevents finding dependent libraries that

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: small fix of libtool.m4

2016-05-09 Thread Richard PALO
Le 10/05/16 02:43, Christian a écrit :
> i’ve had a look again at libtool.m4 and don’t really get why RM is set wrong. 
> obviously the _LT_CONFIG macro literally requires _LT_FILEUTILS_DEFAULT, 
> which should set RM to ‘rm -f’. I also found several uses of $RM with 
> different options, sometimes even ‘-f’. So actually i am not sure what would 
> be the best solution here.
> 
> right now i could change the patch like proposed by Eric Blake to the one i 
> attached. It will at least fix the direct problem i encountered. But maybe 
> for the long term, someone should check and maintain the whole libtool.m4 
> file?!
> 
> kind regards
> christian

I filed https://savannah.gnu.org/support/index.php?108987 a few months ago, 
are you saying the proposed patches don't fix this?

-- 
Richard PALO




avoid issues if CP, MV or RM are predefined in the execution environment

2016-03-19 Thread Richard PALO
Please see problem report and submitted patches 
https://savannah.gnu.org/support/index.php?108987
It would be great if these could be included in the upcoming release.

Currently, and since many years, pkgsrc has patched libtool to simply 'unset' 
CP, MV & RM

This patchset 'fixes' the use as documented, that is to respect the environment 
if these variables
are set, but naturally -- if set -- they will be just the path to the tool and 
as such can in no
way expect that '-f' is specified (which is '--force' under the Gnu flavours of 
these tools).
-- 
Richard PALO


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108987] libtool doesn't like simple RM defined (without options)

2016-03-19 Thread Richard PALO
Additional Item Attachment, sr #108987 (project libtool):

File name: 0001-avoid-issues-if-CP-MV-or-RM-are-predefined-in-the-ex.patch
Size:1 KB
File name: 0002-avoid-issues-if-CP-MV-or-RM-are-predefined-in-the-ex.patch
Size:0 KB


___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


avoid issues if CP, MV or RM are predefined in the execution environment

2016-03-19 Thread Richard PALO
Please see problem report and submitted patches 
https://savannah.gnu.org/support/index.php?108987
It would be great if these could be included in the upcoming release.

Currently, and since many years, pkgsrc has patched libtool to simply 'unset' 
CP, MV & RM

This patchset 'fixes' the use as documented, that is to respect the environment 
if these variables
are set, but naturally -- if set -- they will be just the path to the tool and 
as such can in no
way expect that '-f' is specified (which is '--force' under the Gnu flavours of 
these tools).
-- 
Richard PALO




[sr #108987] libtool doesn't like simple RM defined (without options)

2016-03-18 Thread Richard PALO
Follow-up Comment #3, sr #108987 (project libtool):

The attached patchsets seem to get over the issue for RM, as well as for
eventual problems for CP or MV.

the first patchset (0001-*) is for the master libtool repo,
and the second (0002-*) is for gl-mod/bootstrap in order to 
generate the new bootstrap correctly.

$ env RM=/bin/rm MV=/bin/mv CP=/bin/cp gmake check 

seems fine now

___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108987] libtool doesn't like simple RM defined (without options)

2016-03-01 Thread Richard PALO
Follow-up Comment #2, sr #108987 (project libtool):

It appears that the shell assignment expectation may be erroneous,
in that ": ${RM="rm -f"}" will only replace RM if RM is not defined.

perhaps what is intended is more along the lines of:
RM="${RM:=rm} -f"

(NB it would probably be easier to contend with separating
pure RM from, for example, RM_F (or RM_FORCE) for "rm -f").

This problematic construct seems to be found in at least the following files:
bootstrap, libtool.in, libtool.m4 and funclib.sh

___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108987] libtool doesn't like simple RM defined (without options)

2016-02-28 Thread Richard PALO
Follow-up Comment #1, sr #108987 (project libtool):

another simple, but enlightening way to see this is 
$ env RM=/usr/bin/rm gmake
or 
$ env RM=/usr/bin/rm gmake check

it appears to be more involved than simply updating '${RM}r' to '${RM} -r' in
ltmain.in

___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108987] libtool doesn't like simple RM defined (without options)

2016-02-28 Thread Richard PALO
URL:
  <http://savannah.gnu.org/support/?108987>

 Summary: libtool doesn't like simple RM defined (without
options)
 Project: GNU Libtool
Submitted by: risto3
Submitted on: dim. 28 févr. 2016 14:20:46 GMT
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

noticed on pkgsrc libtool 2.4.2 (patched)
as well as on master

libtool uses a construct in numerous places '${RM}r' where
if defined simply to the full path breaks miserably.

Here is a simple example (code source unimportant):

what works (this is after a --mode=compile stage):

richard@omnis:/home/richard/src/tlibtool$ ../libtool/libtool -v --tag=CXX
--mode=link g++ -shared -o libfoo.la -Wl,-h libfoo.so foo.lo
libtool: link: rm -fr  .libs/libfoo.a .libs/libfoo.la
libtool: link: ar cr .libs/libfoo.a .libs/foo.o 
libtool: link: ranlib .libs/libfoo.a
libtool: link: creating libfoo.la
libtool: link: ( cd ".libs" && rm -f "libfoo.la" && ln -s "../libfoo.la"
"libfoo.la" )

what doesn't:
richard@omnis:/home/richard/src/tlibtool$ RM=/usr/bin/rm ../libtool/libtool -v
--tag=CXX --mode=link g++ -shared -o libfoo.la -Wl,-h libfoo.so foo.lo
libtool: link: /usr/bin/rmr  .libs/libfoo.a .libs/libfoo.la
../libtool/libtool[1851]: eval[1]: /usr/bin/rmr: not found [No such file or
directory]
libtool: link: ar cr .libs/libfoo.a .libs/foo.o 
libtool: link: ranlib .libs/libfoo.a
libtool: link: creating libfoo.la
libtool: link: ( cd ".libs" && /usr/bin/rm "libfoo.la" && ln -s "../libfoo.la"
"libfoo.la" )


libtool should naturally test RM prior to using as thus.




___

Reply to this item at:

  <http://savannah.gnu.org/support/?108987>

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Bug: linking shared libraries on Cygwin results in undefined references to __stack_chck_guard for code compiled with -fstack-protector

2015-09-24 Thread Richard PALO
Le 02/11/13 23:45, Richard PALO a écrit :
> Le 02/06/10 05:24, Yaakov (Cygwin/X) a écrit :
>> On Sat, 15 May 2010 09:07:49 +0200
>> Bart Van Assche <bvanass...@acm.org> wrote:
>>> This behavior has been observed with libtool version 2.2.6.
>>
>> Bug confirmed.  When code is compiled with -fstack-protector{,-all},
>> GCC "emits extra code to check for buffer overflows, such as stack
>> smashing attacks".  This extra code uses symbols from libssp, and
>> therefore (at least) Cygwin's GCC specs contain:
>>
>> *link_ssp:
>> %{fstack-protector|fstack-protector-all:-lssp_nonshared -lssp}
>>
>> Therefore, when libtool fails to pass -fstack-protector{,-all} at link
>> stage, the link fails.
>>
>> Patch attached.  (Yes, I have a copyright assignment on file.)
>>
>>
>> Yaakov
>> Cygwin/X
>>
> 
> I've done some limited testing of this patch on a SunOS distro with 
> pkgsrc, and it certainly helps a number of cases since it is gcc that 
> generates the necessary '-lssp_nonshared -lssp' libs for linking (at 
> least in absence of '-nostdlib').
> 
> Please include in the upcoming version.
> 
> 
> 
> 

I'd like to propose a slight modification this which, in addition, seems to get 
over the
issue (at least on solaris) of c++ shared libraries linking '-nostdlib'.  

This could easily be adapted for other hosts using g++. Note, it is harmless if 
'-dumpspecs'
or no spec with fstack-protector* is available.

It appears there was no warm welcome in tossing the '-nostdlib' setup for g++ 
shared libraries 
for solaris, so this seems to be a reasonable workaround.

-- 
Richard PALO

>From 5dfcf84c8243441f30a3c852791b8d46bc4d2c53 Mon Sep 17 00:00:00 2001
From: Richard PALO <rich...@netbsd.org>
Date: Thu, 24 Sep 2015 13:23:56 +0200
Subject: [PATCH] workaround for -nostdlib with -fstack-protector on solaris

---
 build-aux/ltmain.in | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 0c40da0..7a6356b 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5364,8 +5364,7 @@ func_mode_link ()
   # -stdlib=*select c++ std lib with clang
   -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
   -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \
-  -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
-  -specs=*)
+  -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-stdlib=*|-specs=*)
 func_quote_for_eval "$arg"
 	arg=$func_quote_for_eval_result
 func_append compile_command " $arg"
@@ -5374,6 +5373,25 @@ func_mode_link ()
 continue
 ;;
 
+  -fstack-protector*)
+func_quote_for_eval "$arg"
+arg=$func_quote_for_eval_result
+func_append compile_command " $arg"
+func_append finalize_command " $arg"
+func_append compiler_flags " $arg"
+
+# Explicitly add solaris ssp libs to postdeps to counter
+# linking with g++ -nostdlib when supplied -fstack-protector*
+test CXX = "$tagname" && {
+  case $host_os in
+  solaris*)
+func_append postdeps " `$compile_command -dumpspecs 2>/dev/null | $SED -n '/fstack-protector/{s/^.*://;s/}$//;p;}'`"
+;;
+  esac
+}
+continue
+;;
+
   -Z*)
 if test os2 = "`expr $host : '.*\(os2\)'`"; then
   # OS/2 uses -Zxxx to specify OS/2-specific options
-- 
2.5.2



Re: Bash-specific performance by avoiding sed

2015-03-09 Thread Richard Purdie
On Mon, 2015-03-09 at 18:28 +, Mike Gran wrote:
 I don't know if y'all saw this blogpost where a guy pushed
 the sed regular expression handling into bash-specific
 regular expressions when bash was available.  He claims
 there's a significant performance improvement because of
 reduced forking.
 
 http://harald.hoyer.xyz/2015/03/05/libtool-getting-rid-of-18-sed-forks/

Please see my reply about this. The issue is the amount of looping
through the options parsing code which I did already report here as an
issue.

I do have a fix for it in the build systems I look after:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=cc5f804483a9a1a60be24475baee0eed5d44bef5

which basically unrolls some of the internal code looping and I believe
that with that patch, the speedup to the specific sed invocation you're
looking at will be much less relevant.

The issue is that in its current form, it can't really be merged and my
shell knowledge and lack of contribution agreement to GNU are likely
blocking issues along with a lack of time :(

Cheers,

Richard




___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Performance issue of libtool-2.4.4

2015-02-10 Thread Richard Purdie
On Tue, 2015-02-10 at 10:53 +, Gary V. Vaughan wrote:
 On Feb 10, 2015, at 10:35 AM, Richard Purdie 
 richard.pur...@linuxfoundation.org wrote:
  On Mon, 2015-02-09 at 23:36 +, Richard Purdie wrote:
  On Mon, 2015-02-09 at 13:05 +, Richard Purdie wrote:
  In an effort to get to the bottom of this I made a git bisection, timing
  the performance of building xz with make -j1 using each different
  libtool.
  
  The issues come down to this commit:
  
  http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=0a42997c6032b9550a009a271552e811bfbcc430
  
  libtool: rewritten over funclib.sh instead of general.m4sh.
  
  Before that, I get a time of about 20s, after it, 39s. If I cherry-pick
  in the fix in master mentioned above, I get 27s.
  
  So whilst things are better (thanks!), the above change is still causing
  a regression in the performance somewhere else. Any ideas what else in
  that rather large change may be causing this?
  
  To further narrow this down, of the changes in the above commit, the
  problem appears to be in the changes to the option parsing code. I've
  included the diff below which if I apply on top of the above, I get the
  speed back. I've left the func_split_short_opt/func_split_long_opt code
  in there but that is worth a tiny part of the speed, the issues are
  around the addition of the func_options call.
  
  As yet I don't know enough about the code in question to know why this
  is an issue but traces of libtool show a lot more looping in code to do
  with argument parsing and quoting.
  
  To be more specific, if I take my good libtool and add:
  
  func_options_prep ${1+$@}
  
  it slows the build down by 0.5s on a 21s build. If I look at
  func_options_prep and comment out the line:
  
 func_run_hooks func_options_prep ${1+$@}
  
  I get the 0.5s back.
  
  In func_run_hooks, if I comment:
  
 func_quote_for_eval ${1+$@}
 func_run_hooks_result=$func_quote_for_eval_result
  
  I get the 0.5s back. The issue is all the quoting of the various return
  values through all this looping. It doesn't appear to be hitting the
  printf/sed in func_quote_for_eval which would be an obvious slow path,
  its just the shear number of loops run through with the commandline
  arguments. The change adds a number of calls to func_run_hooks, not just
  the single test case I have above and all combined, it slows things down
  significantly.
  
  So is there a way we can change things so its not calling
  func_quote_for_eval all the time with all the looping that entails?
 
 One possibility would be to add a post-processing script that rewrites
 the hook functions used by func_options into a a single top-level blob of
 sequential shell code.  I imagine that adding some carefully chosen comment
 strings would make extracting the right parts in the right order relatively
 straight forward... it might even be that inlining func_options_prep and
 any hook functions it calls would be enough?

Thanks for the background info on this. I understand the need to change
and improve the software so I'm not proposing reverting, I do think
there has to be some way to get some of the speed here back though.

I have a bit of a pressing need to have a things performing as they were
and I'd prefer to stay on libtool 2.4.5 than revert back to 2.4.2 so I
cooked up the patch I've included below. This basically manually unrolls
the key problematic parts, cut and paste from options-parser. With this
applied to master, I have a build time of 22s compared to 20s or 21s
(need to go and retest as I'm forgetting numbers) with 2.4.2.

For now I'll probably merge something like this into the Yocto
Project/OpenEmbedded, the exact way to solve this longer term is TBD.

Cheers,

Richard




diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index d5cf07a..0f54303 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -342,11 +342,15 @@ _LT_EOF
 # libtool_options_prep [ARG]...
 # -
 # Preparation for options parsed by libtool.
-libtool_options_prep ()
-{
+#libtool_options_prep ()
+#{
 $debug_mode
 
 # Option defaults:
+opt_verbose=false
+opt_warning_types=
+
+# Option defaults:
 opt_config=false
 opt_dlopen=
 opt_dry_run=false
@@ -382,19 +386,14 @@ libtool_options_prep ()
   shift; set dummy --mode uninstall ${1+$@}; shift
   ;;
 esac
-
-# Pass back the list of options.
-func_quote_for_eval ${1+$@}
-libtool_options_prep_result=$func_quote_for_eval_result
-}
-func_add_hook func_options_prep libtool_options_prep
+#}
 
 
 # libtool_parse_options [ARG]...
 # -
 # Provide handling for libtool specific options.
-libtool_parse_options ()
-{
+#libtool_parse_options ()
+#{
 $debug_cmd
 
 # Perform our own loop to consume as many options as possible in
@@ -474,29 +473,90 @@ libtool_parse_options ()
 func_append preserve_args  $_G_opt

Re: Performance issue of libtool-2.4.4

2015-02-10 Thread Richard Purdie
On Mon, 2015-02-09 at 23:36 +, Richard Purdie wrote:
 On Mon, 2015-02-09 at 13:05 +, Richard Purdie wrote:
  In an effort to get to the bottom of this I made a git bisection, timing
  the performance of building xz with make -j1 using each different
  libtool.
  
  The issues come down to this commit:
  
  http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=0a42997c6032b9550a009a271552e811bfbcc430
  
  libtool: rewritten over funclib.sh instead of general.m4sh.
  
  Before that, I get a time of about 20s, after it, 39s. If I cherry-pick
  in the fix in master mentioned above, I get 27s.
  
  So whilst things are better (thanks!), the above change is still causing
  a regression in the performance somewhere else. Any ideas what else in
  that rather large change may be causing this?
 
 To further narrow this down, of the changes in the above commit, the
 problem appears to be in the changes to the option parsing code. I've
 included the diff below which if I apply on top of the above, I get the
 speed back. I've left the func_split_short_opt/func_split_long_opt code
 in there but that is worth a tiny part of the speed, the issues are
 around the addition of the func_options call.
 
 As yet I don't know enough about the code in question to know why this
 is an issue but traces of libtool show a lot more looping in code to do
 with argument parsing and quoting.

To be more specific, if I take my good libtool and add:

func_options_prep ${1+$@}

it slows the build down by 0.5s on a 21s build. If I look at
func_options_prep and comment out the line:

func_run_hooks func_options_prep ${1+$@}

I get the 0.5s back.

In func_run_hooks, if I comment:

func_quote_for_eval ${1+$@}
func_run_hooks_result=$func_quote_for_eval_result

I get the 0.5s back. The issue is all the quoting of the various return
values through all this looping. It doesn't appear to be hitting the
printf/sed in func_quote_for_eval which would be an obvious slow path,
its just the shear number of loops run through with the commandline
arguments. The change adds a number of calls to func_run_hooks, not just
the single test case I have above and all combined, it slows things down
significantly.

So is there a way we can change things so its not calling
func_quote_for_eval all the time with all the looping that entails?

Cheers,

Richard


___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Performance issue of libtool-2.4.4

2015-02-09 Thread Richard Purdie
On Mon, 2015-02-09 at 10:45 +0800, Robert Yang wrote:
 On 02/06/2015 10:46 PM, Bob Friesenhahn wrote:
  On Fri, 6 Feb 2015, Robert Yang wrote:
 
 
 
  On 02/06/2015 12:12 PM, Bob Friesenhahn wrote:
  I am not seeing quite the difference between libtool releases that you are
  although I see a big slowdown starting with 2.4.3.  These timings are for
  optimized builds of GraphicsMagick on a 12-core GNU/Linux system using -j 
  12:
 
  I think that we can't see obviously slowdown by make -jN,
  but make -j1 will. And bash is much slower than dash, I'm trying to
  figure out why.
 
  It seems like this issue is already corrected in the source tree but you are
 
 Yes, I think that the git repo has fixed the problem:
 
 commit 408cfb9c5fa8a666917167ffb806cb19deded429
 Author: Gary V. Vaughan g...@gnu.org
 Date:   Fri Feb 6 12:58:34 2015 +
 
  libtool: don't execute automake and autoconf on every invocation.

In an effort to get to the bottom of this I made a git bisection, timing
the performance of building xz with make -j1 using each different
libtool.

The issues come down to this commit:

http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=0a42997c6032b9550a009a271552e811bfbcc430

libtool: rewritten over funclib.sh instead of general.m4sh.

Before that, I get a time of about 20s, after it, 39s. If I cherry-pick
in the fix in master mentioned above, I get 27s.

So whilst things are better (thanks!), the above change is still causing
a regression in the performance somewhere else. Any ideas what else in
that rather large change may be causing this?

Cheers,

Richard


___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Performance issue of libtool-2.4.4

2015-02-09 Thread Richard Purdie
On Mon, 2015-02-09 at 13:05 +, Richard Purdie wrote:
 In an effort to get to the bottom of this I made a git bisection, timing
 the performance of building xz with make -j1 using each different
 libtool.
 
 The issues come down to this commit:
 
 http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=0a42997c6032b9550a009a271552e811bfbcc430
 
 libtool: rewritten over funclib.sh instead of general.m4sh.
 
 Before that, I get a time of about 20s, after it, 39s. If I cherry-pick
 in the fix in master mentioned above, I get 27s.
 
 So whilst things are better (thanks!), the above change is still causing
 a regression in the performance somewhere else. Any ideas what else in
 that rather large change may be causing this?

To further narrow this down, of the changes in the above commit, the
problem appears to be in the changes to the option parsing code. I've
included the diff below which if I apply on top of the above, I get the
speed back. I've left the func_split_short_opt/func_split_long_opt code
in there but that is worth a tiny part of the speed, the issues are
around the addition of the func_options call.

As yet I don't know enough about the code in question to know why this
is an issue but traces of libtool show a lot more looping in code to do
with argument parsing and quoting.

Cheers,

Richard



--- libtool-bad 2015-02-09 16:34:30.702068736 +
+++ libtool 2015-02-09 23:31:37.238750764 +
@@ -791,13 +791,77 @@
 fi
 }
 
+exit_status=$EXIT_SUCCESS
 
-# libtool_options_prep [ARG]...
-# -
-# Preparation for options parsed by libtool.
-libtool_options_prep ()
-{
-$debug_mode
+# We should try to minimise forks, especially on Windows where they are
+# unreasonably slow, so skip the feature probes when bash or zsh are
+# being used:
+if test set = ${BASH_VERSION+set}$ZSH_VERSION; then
+: ${lt_HAVE_ARITH_OP=yes}
+: ${lt_HAVE_XSI_OPS=yes}
+fi
+
+
+
+# lt_HAVE_XSI_OPS
+# Can be empty, in which case the shell is probed, yes if XSI length
+# and matching operators are useable or anything else if they do not work.
+test -z $lt_HAVE_XSI_OPS \
+ (eval 'x=a/b/c;
+  test 5aa/bb/cc = ${#x}${x%%/*}${x%/*}${x#*/}${x##*/}') 2/dev/null \
+ lt_HAVE_XSI_OPS=yes
+
+
+
+# If this shell supports prefix and suffix pattern removal, then
+# use them to avoid forking. Hide the definition in an eval in case
+# the shell chokes on unsupported syntax...
+if test yes = $lt_HAVE_XSI_OPS; then
+  # func_split_short_opt shortopt
+  # Set func_split_short_opt_name and func_split_short_opt_arg shell
+  # variables after splitting SHORTOPT after the 2nd character.
+  eval 'func_split_short_opt ()
+  {
+$debug_cmd
+
+func_split_short_opt_arg=${1#??}
+func_split_short_opt_name=${1%$func_split_short_opt_arg}
+  }'
+
+  # func_split_long_opt longopt
+  # Set func_split_long_opt_name and func_split_long_opt_arg shell
+  # variables after splitting LONGOPT at the `=' sign.
+  eval 'func_split_long_opt ()
+  {
+func_split_long_opt_name=${1%%=*}
+func_split_long_opt_arg=${1#*=}
+  }'
+else
+  # ...otherwise fall back to using sed.
+  func_split_short_opt ()
+  {
+my_sed_short_opt='1s/^\(..\).*$/\1/;q'
+my_sed_short_rest='1s/^..\(.*\)$/\1/;q'
+
+func_split_short_opt_name=`$ECHO $1 | $SED $my_sed_short_opt`
+func_split_short_opt_arg=`$ECHO $1 | $SED $my_sed_short_rest`
+  }
+
+  func_split_long_opt ()
+  {
+my_sed_long_opt='1s/^\(--[^=]*\)=.*/\1/;q'
+my_sed_long_arg='1s/^--[^=]*=//'
+
+func_split_long_opt_name=`$ECHO $1 | $SED $my_sed_long_opt`
+func_split_long_opt_arg=`$ECHO $1 | $SED $my_sed_long_arg`
+  }
+fi
+
+debug_cmd=${debug_cmd-':'}
+opt_warning=:
+opt_verbose=:
+opt_verbose=false
+exit_cmd=:
 
 # Option defaults:
 opt_config=false
@@ -836,26 +900,23 @@
   ;;
 esac
 
-# Pass back the list of options.
-func_quote_for_eval ${1+$@}
-libtool_options_prep_result=$func_quote_for_eval_result
-}
-func_add_hook func_options_prep libtool_options_prep
 
 
-# libtool_parse_options [ARG]...
-# -
-# Provide handling for libtool specific options.
-libtool_parse_options ()
+# Parse options once, thoroughly.  This comes as soon as possible in the
+# script to make things like `--version' happen as quickly as we can.
 {
-$debug_cmd
-
 # Perform our own loop to consume as many options as possible in
 # each iteration.
 while test $# -gt 0; do
   _G_opt=$1
   shift
   case $_G_opt in
+
+--debug|-x)debug_cmd='set -x'
+   func_echo enabling shell trace mode
+   $debug_cmd
+   ;;
+
 --dry-run|--dryrun|-n)
 opt_dry_run=:
 ;;
@@ -927,29 +988,39 @@
 func_append preserve_args  $_G_opt
 ;;
 
-   # An option not handled by this hook function:
-*) set dummy $_G_opt

Re: g++ and -nostdlib

2014-04-12 Thread Richard PALO

Le 09/11/13 07:44, Richard PALO a écrit :

I believe Chuck is oriented in the right direction.

A good example is with -fstack-protector.

gcc/g++ knows how to link depending upon whether the platforms libc has
SSP support or not.

I doubt very much that libtool wants to figure out whether to add the
specific libraries necessary for SSP to the link command.
It *should* however pass through the provided flags to the compiler
driver, and not strip in this case '-fstack-protector'; object of:

Bug: linking shared libraries on Cygwin results in undefined
references to __stack_chck_guard for code compiled with -fstack-protector


In this particular worst case, '-fstack-protector' is stripped, and
even if it passed through, the g++ '-nostdlib' defeats the purpose!






Just a comment to keep this thread alive, I've been testing this patch 
since it came out adapted for solaris using libtool 2.4.2 on 
pkgsrc-current along with the following two patches:

[PATCH] Fix linking with -fstack-protector
bug#16452: opt_duplicate_compiler_generated_deps is harmful on Solaris

The description is available on tech-...@netbsd.org in the thread: 
libtool, -fstack-protector, -nostdlib, and while we're at it -Bdirect 
on SunOS


Earlier issues with perl and cups involving '-fstack-protector' seem 
resolved and, as indicated elsewhere, '-pthread' as well (albeit already 
worked around in many pkgsrc packages or the distros themselves.


If there is/are any use case(s) that break with this patch (I believe as 
Bob feared) they should be explicitly detailed and examined for the 
cause, otherwise there seems to be more merit in pushing this patch than 
suffering the current side effects.


cheers






Re: g++ and -nostdlib

2014-04-12 Thread Richard PALO

Le 09/11/13 07:44, Richard PALO a écrit :

I believe Chuck is oriented in the right direction.

A good example is with -fstack-protector.

gcc/g++ knows how to link depending upon whether the platforms libc has
SSP support or not.

I doubt very much that libtool wants to figure out whether to add the
specific libraries necessary for SSP to the link command.
It *should* however pass through the provided flags to the compiler
driver, and not strip in this case '-fstack-protector'; object of:

Bug: linking shared libraries on Cygwin results in undefined
references to __stack_chck_guard for code compiled with -fstack-protector


In this particular worst case, '-fstack-protector' is stripped, and
even if it passed through, the g++ '-nostdlib' defeats the purpose!






Just a comment to keep this thread alive, I've been testing this patch 
since it came out adapted for solaris using libtool 2.4.2 on 
pkgsrc-current along with the following two patches:

[PATCH] Fix linking with -fstack-protector
bug#16452: opt_duplicate_compiler_generated_deps is harmful on Solaris

The description is available on tech-...@netbsd.org in the thread: 
libtool, -fstack-protector, -nostdlib, and while we're at it -Bdirect 
on SunOS


Earlier issues with perl and cups involving '-fstack-protector' seem 
resolved and, as indicated elsewhere, '-pthread' as well (albeit already 
worked around in many pkgsrc packages or the distros themselves.


If there is/are any use case(s) that break with this patch (I believe as 
Bob feared) they should be explicitly detailed and examined for the 
cause, otherwise there seems to be more merit in pushing this patch than 
suffering the current side effects.


cheers




___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Libtool 2.4.3 release

2014-03-20 Thread Richard Purdie
On Thu, 2014-03-20 at 18:07 +1300, Gary V. Vaughan wrote:
 On Mar 20, 2014, at 5:37 AM, Arnout Vandecappelle
 arnout.vandecappe...@essensium.com wrote:
  [Please keep me in CC, I'm not on the list]
  Dear libtool maintainers,

  Is there a possibility for a new libtool release in the foreseeable
  future?

 Yes, absolutely. In fact there are only 2 things ahead of it on my
 TODO list:

   1. Figure out why a4ffcdb5e is a regression for test 57
   2. fix test 120 race condition

 Unfortunately, Libtool is a complex beast, and we are woefully
 undermanned here.
 While everything rests on my shoulders, it will be at least another
 month before I can start work (I'm in the process of emigrating and
 all that entails).

 Patches for those 2 items, or any other as yet unknown issues with git
 master (or http://vaughan.pe/libtool/libtool-2.4.2.458.tar.gz if a
 bootstrapped tarball is easier to work with) are extremely welcome,
 and could lead to an immediate release...

FWIW I'm another build system maintainer who sees email here. We
currently have 12 patches against libtool:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/libtool/libtool

Some of these are inappropriate for upstream, one or two may have been
merged into libtool, some others may highlight issues, particularly
around the sysroot support.

Unfortunately whilst I have the best intentions (and am still on the
list), I haven't found the time to look into the issues as yet and
figure out if we could get some into a form that they'd be accepted
upstream.

Cheers,

Richard




___
https://lists.gnu.org/mailman/listinfo/libtool


Re: g++ and -nostdlib

2014-01-23 Thread Richard PALO

Le 22/01/14 17:54, Richard PALO a écrit :

I already have a question to see this through:

Does it sound reasonable to add support to inherit_linker_flags
'-fstack-protector|-fstack-protector-all'
in a similar manner to '-pthreads' given the compiler needs to have this
option in order to include the correct libraries...



As the name seems to indicate, this appears thus far as unnecessary as 
the shared libraries only need '-fstack-protector' to be built, and not 
when utilised by a client.

Nice exercise to see how it worked, though;-)


___
https://lists.gnu.org/mailman/listinfo/libtool


Re: g++ and -nostdlib

2014-01-22 Thread Richard PALO

Le 06/12/13 09:51, Peter Rosin a écrit :

[dropping libtool-patches@]

On 2013-11-12 12:24, Peter Rosin wrote:

[re-adding libtool@]

On 2013-11-11 16:10, Bob Friesenhahn wrote:

On Mon, 11 Nov 2013, Peter Rosin wrote:


Quite a lot of effort went into making this work the way it currently does.


I realize that, but if it really works or not is a different question :-)


Yes, of course. It is obviously primarily working as demonstrated
by the massive amount of software linked for years and years using
libtool.


Right, I wasn't really serious.


I.e., as far as I can tell, $LD is not used for linking. $CXX is used, with
-nostdlib and some manually detected libs/objects, which end up wrong if
different flags (such as -pthread) are used when digging and actually linking.


Yes, GCC has known bugs with reporting the libraries which would
actually be used based on proposed arguments. It must be the case
that GCC maintainers don't consider this to be a bug since GCC has
not changed its behavior.


Even if GCC did report dependent libs correctly (for the libtool version
of correctly), libtool would have a difficult time replicating what libs
to actually apply if one project builds a number of libraries/programs
with different GCC options. It's a bit fragile by design.


Googling a bit more turned up this old quote from Ralf [1] on this subject:

   BTW, I believe libtool does the -nostdlib stuff because, at least in the 
past,
   not using it could cause situations where later libstdc++ would not be found
   automatically.  I think at least for dlopen'ed modules depending on C++
   libraries this is still the case (completely untested).

That was 8 years ago, even then it appears noone really knew why -nostdlib
is used (which is interesting in itself).


As far as I am aware, the issue is primarily due to some C++ standard
libraries being delivered as static libraries (usually due to C++
exceptions problems) and therefore necessitating being linked to the
dependent executable rather than into a shared library (which may
then be linked with other shared libraries linked into an
executable). This magic is done via information cached in the .la
files.


And why wouldn't the standard library be picked up again by the compiler
driver when linking the dependent executable?


And why do I not find any such info in the .la file for the attached test
case?


Intuiting all the libraries which would be used has been a core
tenant of libtool given that it attempts to record all the linkage
dependencies in its .la files.


I don't understand why it is necessary to relist dependencies that
the compiler driver is going to find anyway. Why does libtool need
this degree of control?


So, someone needs to write some test cases that tries to build a library
with --static-libgcc and then use that in a program w/o --static-libgcc
(and vice versa), as well as doing some dlopen test with C++ modules to
try to deduce if the above problem described by Ralf can still be
reproduced (but his wording suggest that it might be subtle). And lastly we
might need some test that tries to throw C++ exceptions over DLL boundaries,
if that isn't already done by tests/exceptions.at...


The tests/exceptions.at tests the ability to catch exceptions thrown
from a DLL. It is not uncommon for it to fail with GCC for certain
targets due to target-specific libtool bugs or GCC compiler bugs.
Even with this test, it very difficult to tell if the C++ exceptions
framework is really working. In my experience, C++ exceptions are
reliably working with proprietary compilers and sometimes failing
with GCC.


Ok, so this test sometimes fails even if libtool tries to be clever.
Maybe it fails because libtool is too clever? It would be interesting
to know if the test continues to fail if libtool just trusts the
compiler driver (i.e. with the patch applied). I can't tell, because
the test works both with and without the patch for me.


In my opinion, this topic is significant enough that it should be
discussed on the general libtool list before any decision to rip out
the existing special GCC support and treat GCC similar to other
compilers.


I didn't notice that libtool@ was dropped by Chuck. So, I'm switching
to that list instead. Please drop libtool-patches@ next time.

Anyway, when I started this thread, my main interest was to understand
*why* libtool does the -nostdlib dance. But as I'm not personally
affected by it, I'm not really pushing for my patch, it is mainly there
to trigger discussion. What I would like to see is some test cases that
actually fails when libtool simply trusts GCC to DTRT. Currently the
test suite is clean with my patch, at least on Cygwin. If we have some
test cases we know what is sacrificed if -nostdlib is dropped.

If we can't construct a valid test case that works with -nostdlib, but
fails without it, that would be quite telling though...

So, can someone conjure up such a test case? I can't, I'd be fumbling and
wouldn't know 

Re: g++ and -nostdlib

2014-01-22 Thread Richard PALO

I already have a question to see this through:

Does it sound reasonable to add support to inherit_linker_flags
'-fstack-protector|-fstack-protector-all'
in a similar manner to '-pthreads' given the compiler needs to have this 
option in order to include the correct libraries...




___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Patch for bug#16452: opt_duplicate_compiler_generated_deps is harmful on Solaris

2014-01-17 Thread Richard PALO

Le 17/01/14 15:02, Rainer Orth a écrit :

As reported in

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16452

the default for opt_duplicate_compiler_generated_deps can cause
exception handling/unwinding failures on 64-bit Solaris 10+/x86 when the
underlying gcc bug

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59788

is fixed.  The libtool bug report already contains the fix for the
version of libtool bundled in the gcc repo.  I'd like to include the
patch from the gcc bug report in the upcoming next gcc release, 4.9.0.
gcc policy requires that such patches have to be accepted for upstream
libtool first, so here's the patch to git libtool:




It has been tested on i386-pc-solaris2.10 with gcc 4.8 without testsuite
regressions.

Rainer



This is quite interesting as it appears to explain some issues I've been 
encountering.. and will test to see how it works.


If I'm not mistaken, ltmain.sh and ltmain.in (formerly ltmain.m4sh) 
should be kept synchronised in the source tree...





Re: g++ and -nostdlib

2013-11-08 Thread Richard PALO

Le 08/11/13 20:07, Charles Wilson a écrit :

On 11/8/2013 1:49 PM, Bob Friesenhahn wrote:

Isn't it because libtool wants to control the order of the linking and
assure that all dependencies (including static) are tracked/known and
applied at the correct times?  It wants to assure that static
dependencies are linked into the dependent program rather than into some
dependent shared library (and thus causing a problem).

It was common (and perhaps still is) for the GNU C++ library to be
delivered as a static library for Windows/MinGW because C++ exceptions
were not handled properly when thrown by DLLs.

Quite a lot of effort went into making this work the way it currently
does.

First libtool tries to take away all of the libraries which would be
added automatically and then it applies the libraries that GCC says it
would use at the correct time.


One of my wishlist roundtuit items is to special-case this behavior for
libtool + GNU toolchains.  For that combo, instead of the procedure Bob
outlines, and then using $LD to linkjust use the compiler driver
(e.g. g++, or gfortran, or gcc) to link, WITHOUT -nostdlib [1].  We're
already passing the ABI-modifying -m and -f flags anyway, and it would
really REALLY simplify libtool's logic...

[1] unless of course the end user put -nostdlib in $LDFLAGS or something.

--
Chuck





I believe Chuck is oriented in the right direction.

A good example is with -fstack-protector.

gcc/g++ knows how to link depending upon whether the platforms libc has 
SSP support or not.


I doubt very much that libtool wants to figure out whether to add the 
specific libraries necessary for SSP to the link command.
It *should* however pass through the provided flags to the compiler 
driver, and not strip in this case '-fstack-protector'; object of:

Bug: linking shared libraries on Cygwin results in undefined  references to 
__stack_chck_guard for code compiled with -fstack-protector


In this particular worst case, '-fstack-protector' is stripped, and 
even if it passed through, the g++ '-nostdlib' defeats the purpose!








Re: Bug: linking shared libraries on Cygwin results in undefined references to __stack_chck_guard for code compiled with -fstack-protector

2013-11-02 Thread Richard PALO

Le 02/06/10 05:24, Yaakov (Cygwin/X) a écrit :

On Sat, 15 May 2010 09:07:49 +0200
Bart Van Assche bvanass...@acm.org wrote:

This behavior has been observed with libtool version 2.2.6.


Bug confirmed.  When code is compiled with -fstack-protector{,-all},
GCC emits extra code to check for buffer overflows, such as stack
smashing attacks.  This extra code uses symbols from libssp, and
therefore (at least) Cygwin's GCC specs contain:

*link_ssp:
%{fstack-protector|fstack-protector-all:-lssp_nonshared -lssp}

Therefore, when libtool fails to pass -fstack-protector{,-all} at link
stage, the link fails.

Patch attached.  (Yes, I have a copyright assignment on file.)


Yaakov
Cygwin/X



I've done some limited testing of this patch on a SunOS distro with 
pkgsrc, and it certainly helps a number of cases since it is gcc that 
generates the necessary '-lssp_nonshared -lssp' libs for linking (at 
least in absence of '-nostdlib').


Please include in the upcoming version.





Re: libtool - warnings when installing GMP using DESTDIR

2013-09-20 Thread Richard Purdie
On Thu, 2013-09-19 at 15:58 -0400, Michael Young wrote:
 I'm trying to do a staged build/install of libgmp(xx) release 5.1.2.
  This is
 part of an effort to develop a general build system (mostly bash
 scripts, make
 files, etc.) for toolchains I will be using.  I intend to use these
 scripts to
 build both native and cross-builds, depending on configuration /
 arguments, so
 using DESTDIR for prefixing the install tree is important.  Right now,
 I'm 
 working on native builds on an Ubuntu 12.04 32-bit x86 machine;
 libtool 
 version = 2.4.2.)
 
I can't help with the libtool issue but there are several build systems
out there that already have these issues solves such as the one I work
on:

http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html

which runs on Linux and can build cross compilers targeting the common
architectures and the cross compiler itself can run on linux, windows
and osx.

Cheers,

Richard


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2013-02-24 Thread Richard PALO
Follow-up Comment #31, sr #108201 (project libtool):

apparently Joyent believe that this isn't closed, if there is somebody that
has tested this too could determine whether or not to close the issue as
fixed, thanks in advance.

___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Re-ordering of libraries by libtool.

2013-02-24 Thread Richard Shann
Thank you for the thoughtful response.
On Sun, 2013-02-24 at 10:50 -0600, Bob Friesenhahn wrote:
 On Wed, 20 Feb 2013, Richard Shann wrote:
 
  In the GNU/Denemo project we are trying to cross-build a for windows on
  Debian stable using static libraries. The libtool step is re-ordering
  the libraries before invoking the linker, and so it fails.
  The cross-environment has version 2.22 of GNU/Binutils, but I am not
  clear where the actual libtool is coming from - the host libtool is
  version 2.26b.
 
 It is not wise to use such an archaic libtool.  You can determine 
 which version is actually used by doing './libtool --version' in the 
 build tree.
My problem was that the build is done with some environment set, without
hacking at it I cannot be sure what is being invoked (the tools are
being built for doing the compiling and linking as well as the final
executable)
 
  I can't find online documentation for this version, and even in the
  latest version there is almost no mention of libtool re-ordering the
  directories as given. I noticed one previous email on this topic, which
  received no responses. Can someone help?
 
 If any libraries have .la files, then this cause libtool to inject 
 library dependencies (additional needed libraries) into the build, 
 which may have the apparent effect of re-ordering.
But that is intended to be only an apparent effect - the later
appearance of the library on the link line would surely not be deleted?
This is what I appeared to encounter - no matter how many times I listed
the set of libraries on the $(CXXLD) line a symbol which nm says was
defined in a library was not found.
 
 Regardless, you should be using libtool 2.4.2.  Libtool 2.2.6b is a a 
 security-patched version of libtool 2.2.6a, which was released in 
 2008.
Yes Debian stable is always about 2 years behind; I guess that is why it
is called stable :) Trying to mix-and-match components is (for me) an
exercise in frustration.

Once again, thanks - at the moment we have returned to trying to build
using GNU/LilyPond's GUB system...

Richard Shann








___
https://lists.gnu.org/mailman/listinfo/libtool


Re-ordering of libraries by libtool.

2013-02-20 Thread Richard Shann
In the GNU/Denemo project we are trying to cross-build a for windows on
Debian stable using static libraries. The libtool step is re-ordering
the libraries before invoking the linker, and so it fails.
The cross-environment has version 2.22 of GNU/Binutils, but I am not
clear where the actual libtool is coming from - the host libtool is
version 2.26b.
I can't find online documentation for this version, and even in the
latest version there is almost no mention of libtool re-ordering the
directories as given. I noticed one previous email on this topic, which
received no responses. Can someone help?
Below is the libtool step as recorded in the log of the build (it is
being done using the mxe cross-compiling makefile system).
In the link the symbold register_evince_backend is defined in the
libpdfdocument.a which starts off after the libevdocument.a on the line
that /bin/bash gets, but is moved later when libtool executes the
linker. (Or so at least is my reading of this log).
Richard Shann
888
[...]
/bin/bash ../libtool --tag=CXX   --mode=link i686-pc-mingw32-g++  -g -O2
-o denemo.exe denemo_types.o commands.o calculatepositions.o
changenotehead.o chordops.o clefdialog.o commandfuncs.o contexts.o
draw.o drawaccidentals.o drawclefs.o drawcursor.o drawkey.o
drawdynamic.o drawnotes.o drawselection.o drawstemdir.o drawtimesig.o
drawtuplets.o drawlyric.o dynamic.o drawfigure.o exportabc.o
exportlilypond.o articulations.o exportxml.o file.o hairpin.o help.o
importxml.o importmusicxml.o importmidi.o kbd-custom.o kbd-interface.o
keyresponses.o keysigdialog.o figure.o main.o measureops.o
moveviewport.o mousing.o barline.o view.o http.o mwidthdialog.o objops.o
exportmidi.o instrumentname.o external.o source.o sourceaudio.o
scorelayout.o playback.o drawfakechord.o fakechord.o playbackprops.o
prefdialog.o prefops.o processstaffname.o lyric.o scoreops.o
scoreprops.o selectops.o staffops.o staffpropdialog.o drawbarline.o
slurs.o timedialog.o tomeasuredialog.o tupletops.o utils.o graceops.o
runsilent.o drawgrace.o print.o texteditors.o binreloc.o bookmarks.o
parseinstruments.o keyboard.o pitchentry.o pitchrecog.o drawlilydir.o
lilydirectives.o displayanimation.o midi.o audiocapture.o screenshot.o
\
/home/rshann/mxe/usr/i686-pc-mingw32/lib/libintl.a
-L/home/rshann/mxe/usr/i686-pc-mingw32/lib 
/home/rshann/mxe/usr/i686-pc-mingw32/lib/libiconv.a ../libsmf/libsmf.a 
libaudiobackend.a ../libsffile/libsffile.a 
/home/rshann/mxe/usr/i686-pc-mingw32/lib/libguile-srfi-srfi-1-v-3.a 
/home/rshann/mxe/usr/i686-pc-mingw32/lib/libguile-srfi-srfi-60-v-2.a 
/home/rshann/mxe/usr/i686-pc-mingw32/lib/libevview.a 
/home/rshann/mxe/usr/i686-pc-mingw32/lib/libevdocument.a 
/home/rshann/mxe/usr/i686-pc-mingw32/lib/evince/3/backends/libpdfdocument.a 
/home/rshann/mxe/usr/i686-pc-mingw32/lib/libpoppler.a 
/home/rshann/mxe/usr/i686-pc-mingw32/lib/libpoppler-cpp.a 
/home/rshann/mxe/usr/i686-pc-mingw32/lib/libpoppler-glib.a  -lportmidi  
-L/home/rshann/mxe/usr/i686-pc-mingw32/lib -lguile -lregex -lgmp -lws2_32 -lm 
-lltdl -lunistring -lintl -liconv   -L/home/rshann/mxe/usr/i686-pc-mingw32/lib 
-lxml2 -lz -liconv -lws2_32   -L/home/rshann/mxe/usr/i686-pc-mingw32/lib 
-lrsvg-2 -lgdk_pixbuf-2.0 -lgsf-1 -lpangocairo-1.0 -lcroco-0.6 -ltiff -llzma 
-ljpeg -lgio-2.0 -ldnsapi -lcairo -lmsimg32 -lpangoft2-1.0 -lpangowin32-1.0 
-lgdi32 -lpixman-1 -lpng15 -lfontconfig -lexpat -lfreetype -lbz2 -lpango-1.0 
-lm -lusp10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lole32 
-lshlwapi -lpcre -lintl -lxml2 -lz -liconv -lws2_32   
-L/home/rshann/mxe/usr/i686-pc-mingw32/lib -lfontconfig -lexpat -lfreetype -lz 
-lbz2 -liconv   -L/home/rshann/mxe/usr/i686-pc-mingw32/lib -lgthread-2.0 
-lglib-2.0 -lws2_32 -lole32 -lshlwapi -lpcre -lintl -liconv   
-L/home/rshann/mxe/usr/i686-pc-mingw32/lib -lsndfile -lFLAC -lwsock32 
-lvorbisenc -lvorbis -lm -logg-L/home/rshann/mxe/usr/i686-pc-mingw32/lib 
-lgtk-win32-2.0 -lwinspool -lcomctl32 -lcomdlg32 -lgdk-win32-2.0 -limm32 
-lshell32 -luuid -latk-1.0 -lpangocairo-1.0 -lgio-2.0 -ldnsapi -lgdk_pixbuf-2.0 
-lpangoft2-1.0 -lpangowin32-1.0 -lpango-1.0 -lm -lusp10 -lcairo -lmsimg32 
-lgdi32 -lpixman-1 -lfontconfig -lexpat -lfreetype -lbz2 -ltiff -llzma -ljpeg 
-lpng15 -lz -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lws2_32 
-lole32 -lshlwapi -lpcre -lintl -liconv   
-L/home/rshann/mxe/usr/i686-pc-mingw32/lib -lgtksourceview-2.0 -lxml2 
-lgtk-win32-2.0 -lwinspool -lcomctl32 -lcomdlg32 -lgdk-win32-2.0 -limm32 
-lshell32 -luuid -latk-1.0 -lpangocairo-1.0 -lgio-2.0 -ldnsapi -lgdk_pixbuf-2.0 
-lpangoft2-1.0 -lpangowin32-1.0 -lpango-1.0 -lm -lusp10 -lcairo -lmsimg32 
-lgdi32 -lpixman-1 -lfontconfig -lexpat -lfreetype -lbz2 -ltiff -llzma -ljpeg 
-lpng15 -lz -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lws2_32 
-lole32 -lshlwapi -lpcre -lintl -liconv
-L/home/rshann/mxe/usr/i686-pc-mingw32/lib -levview -levdocument 
-lgtk-win32-2.0 -lwinspool -lcomctl32 -lcomdlg32 -lgdk-win32

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-23 Thread Richard PALO
Follow-up Comment #30, sr #108201 (project libtool):

The following patch to export.at seems to work on solaris

now testing for ELF in the shared object and using shrext_cmds to generate the
.so extension.


(file #27141)
___

Additional Item Attachment:

File name: export.at.git-diff Size:1 KB


___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-19 Thread Richard PALO
Follow-up Comment #27, sr #108201 (project libtool):

This is fine with me.

When *is* the next release planned then? 

In the meanwhile I will try to finish a pkgsrc patch to the already released
bits (which seems to complain with auto* tools)...

cheers



___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-18 Thread Richard PALO
Follow-up Comment #25, sr #108201 (project libtool):

These are good arguments, I offer as well some observations and/or arguments
before I sign off...

1. I thought about that last night, that *was* the advantage of elfdump, but
not all ELF systems have elfdump and objdump is used instead! Perhaps the
libtool system could put the mechanisms in place to indicate via the --config
command that the target platform is ELF in order to better instrument the
test case.

2. I initially wanted to use soname_spec, but there were too many fields
missing and I couldn't seem to get it right.  Now I see that
'shrext_cmds=.so' is in config so perhaps that could be used to generate the
file extension.
something like  '$objdir/liba$shrext_cmds'

3. I believe absence of a shared file being generated (on an ELF platform)
would be already a sign of a test failure!

4. The objdump chosen by libtools configure should be for the target... I
didn't check, but that *is* already the responsability of the build
environment.


Regarding zapping of $LDFLAGS, I compared this case (GXX) with the GCC case,
and indeed GXX seemed again in error, justifying your remarks.  Here is an
extract from GCC for comparison:

solaris*)
  _LT_TAGVAR(no_undefined_flag, $1)=' -z defs'
  if test yes = $GCC; then
wlarc='$wl'
_LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $wl-z ${wl}text
$wl-h $wl$soname -o $lib $libobjs $deplibs $compiler_flags'
_LT_TAGVAR(archive_expsym_cmds, $1)='echo { global:  $lib.exp~cat
$export_symbols | $SED -e s/(.*)/1;/  $lib.exp~echo local: *; }; 
$lib.exp~
  $CC -shared $pic_flag $wl-z ${wl}text $wl-M $wl$lib.exp $wl-h
$wl$soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp'
  else

I don't believe Green Hills C++ code path is touched here, the patch I
submitted touches only Gnu CXX with solaris ld.

To summarize, I believe the libtool.m4 code patch should move ahead, but I
agree that the libtool testsuite could be (globally) improved to deal with
shared libraries on the different plastforms. 

By the way, given pkgsrc is preparing for 2012Q4, it is urgent to release a
patched kit. 

I've attached the combined diff upon libtool.m4

cheers

(file #27123)
___

Additional Item Attachment:

File name: libtool.m4.git-diffSize:2 KB


___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-16 Thread Richard PALO
Follow-up Comment #19, sr #108201 (project libtool):

Well, I can certainly understand your reluctance to spend much more time on
this, as I never really intended myself to do more than suggest a patch that
fixes a libtool bug on solaris with gcc and solaris ld.  

Adding the test functionality is more or less a moral responsability when
suggesting the bugfix.  Unfortunately, being an indirect libtool user and not
a developer, I cannot do more than demonstrate the additional problem.

The testsuite problems in master (see comment #1) enticed me to focus on the
version I'm testing in pkgsrc, namely in test v2.4.2 and in stable 2.2.6b).

BTW, perhaps it is buried in the comments below, but at least on the solaris
platform, -no-undefined is by default, because if I change LDFLAGS to
-Wl,-z -Wl,defs or -Wl,--no-undefined I get a warning that the option
specified is a duplicate.

I do feel that the patch is warranted on 2.4.2 (perhaps generating patch
release v2.4.2a or v2.4.3) and also in the master, so I will submit another
patch, as Bob indicated, for the master and consider the 2.4.2 patch as a
backport.

As the elements are provided to include the missing test functionality in
export.at, I will leave that to the release team given the massive
reoganisation of the sources, the tests will certainly need some generally
updating.  The case here is a good example...  

I noticed in the document README-release that prior to releasing that

make distcheck CC=g++

should be executed.

I believe that  

  make check-local CC=g++ 

should also be executed and when it works, that is with a recent gcc (4.7.x),
then the libtool and the testsuite are ready for release on a Linux/unix
platform.

Cheers

___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-16 Thread Richard PALO
Follow-up Comment #21, sr #108201 (project libtool):

Here is the git diff for master (apparently the same except for the file
path).

(file #27107)
___

Additional Item Attachment:

File name: libtool.m4.git-diff-master Size:1 KB


___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-15 Thread Richard PALO
Follow-up Comment #15, sr #108201 (project libtool):

could you please post your testsuite.log for the following command:

gmake CC=g++ check-local

it is possible that this is yet another bug (either in libtool or in gcc...)

When I only run test 45 with

gmake CC=g++ check-local TESTSUITEFLAGS=45 -d

The test fails with the following extract from
tests/testsuite.dir/045/testsuite.log :
==
eval '/home/richard/src/libtool/libtool --mode=link g++ -g -O2  -no-undefined
-o liba.la a.lo 
   -rpath
/home/richard/src/libtool/tests/testsuite.dir/045/inst/lib' 
./export.at:171: eval '$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba.la
a.lo 
   -rpath $libdir' $exportsyms
stderr:
g++: error: unrecognized command line option '-no-undefined'
stdout:
libtool: link: g++ -shared  -fPIC -DPIC -nostdlib  -no-undefined
/usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o /opt/pkg/gcc47/lib
/gcc/x86_64-sun-solaris2.11/4.7.2/crtbegin.o  .libs/a.o  
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2 -L/opt/pkg/gcc47/lib
/gcc/x86_64-sun-solaris2.11/4.7.2/../../../../x86_64-sun-solaris2.11/lib/amd64
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2
/../../../amd64 -L/lib/amd64 -L/usr/lib/amd64
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/../../../../x86_64-sun-solaris2.
11/lib -L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/../../.. -lstdc++
-lm -lc -lgcc_s /opt/pkg/gcc47/lib/gcc/x86_64-sun-sol
aris2.11/4.7.2/crtend.o /usr/lib/amd64/crtn.o  -O2   -Wl,-h -Wl,liba.so.0 -o
.libs/liba.so.0.0.0
./export.at:171: exit code was 1, expected 0






___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-15 Thread Richard PALO
Follow-up Comment #17, sr #108201 (project libtool):

I gather that your gcc is rather ancient (4.5.3 from april 2011) but I cannot
determine which version of libtool you are using.

Would it be possible to upgrade gcc to the latest 4.7.2 and

git checkout v2.4.2 

in order to update your repository as well.  I'm dubious testing a version
that is not the last stable.

I agree that the export test (45) is sufficient as it adds '-no-undefined' to
LDFLAGS.  Thanks for the 'k export' hint.
That is, in effect, what I do.

Thank you in advance

___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-13 Thread Richard PALO
Follow-up Comment #12, sr #108201 (project libtool):

perhaps to refine the test a bit more, would it be possible to check that the
value of SONAME is the value expected.

With elfdump, the SONAME could be extracted for example by:

elfdump -d $soname | grep SONAME | awk '{printf $4}'

Apparently when in absence of elfdump, linux has objdump:

objdump -p $soname | grep SONAME | awk '{printf $2}'

It has been over a decade since I touched a compiler on W32, so I wouldn't
even attempt to determine the equivalent.

Again, the maintainer probably [has|should have] this knowledge.

___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-13 Thread Richard PALO
Follow-up Comment #13, sr #108201 (project libtool):

if the solaris developer/gnu-binutils or pkgsrc/devel/binutils is installed,
then objdump is on the system.

Just noticed that libtool's configure found objdump:
richard@devzone:~/src/libtool$ grep objdump config*
config.log:configure:5686: checking for objdump
config.log:configure:5702: found /opt/pkg/gnu/bin/objdump
config.log:configure:5713: result: objdump
config.log:ac_cv_prog_ac_ct_OBJDUMP=objdump
config.log:OBJDUMP='objdump'
config.status:OBJDUMP='objdump'
config.status:S[OBJDUMP]=objdump
configure:  # Extract the first word of ${ac_tool_prefix}objdump, so it can
be a program name with args.
configure:set dummy ${ac_tool_prefix}objdump; ac_word=$2
configure:ac_cv_prog_OBJDUMP=${ac_tool_prefix}objdump
configure:  # Extract the first word of objdump, so it can be a program name
with args.
configure:set dummy objdump; ac_word=$2
configure:ac_cv_prog_ac_ct_OBJDUMP=objdump
configure:test -z $OBJDUMP  OBJDUMP=objdump
configure:  # func_win32_libid shell function, so use a weaker test based on
'objdump',
configure:  # use the weaker test based on 'objdump'. See mingw*.
configure:  # Extract the first word of ${ac_tool_prefix}objdump, so it can
be a program name with args.
configure:set dummy ${ac_tool_prefix}objdump; ac_word=$2
configure:ac_cv_prog_OBJDUMP=${ac_tool_prefix}objdump
configure:  # Extract the first word of objdump, so it can be a program name
with args.
configure:set dummy objdump; ac_word=$2
configure:ac_cv_prog_ac_ct_OBJDUMP=objdump
configure:test -z $OBJDUMP  OBJDUMP=objdump

I don't believe binutils is explicitly a libtool prerequisite, though, in
order to use only $OBJDUMP in this case.


___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-12 Thread Richard PALO
Follow-up Comment #5, sr #108201 (project libtool):

Here is my feable and first attempt to detect the problem using the
testsuite.

First, the test export.at seems to work by default, but it is only a gcc
(simple 'C') test:

richard@devzone:~/src/libtool$ gmake check-local TESTSUITEFLAGS=45 -d
cd ./tests  
autom4te --language=autotest `echo tests/testsuite.at tests/getopt-m4sh.at
tests/libtoolize.at tests/help.at tests/duplicate_members.at
tests/duplicate_conv.at tests/duplicate_deps.at tests/flags.at
tests/inherited_flags.at tests/convenience.at tests/link-order.at
tests/link-order2.at tests/fail.at tests/shlibpath.at
tests/runpath-in-lalib.at tests/static.at tests/export.at tests/search-path.at
tests/indirect_deps.at tests/archive-in-archive.at tests/exeext.at
tests/execute-mode.at tests/bindir.at tests/cwrapper.at
tests/deplib-in-subdir.at tests/infer-tag.at tests/localization.at
tests/nocase.at tests/install.at tests/versioning.at tests/destdir.at
tests/old-m4-iface.at tests/am-subdir.at tests/lt_dlexit.at
tests/lt_dladvise.at tests/lt_dlopen.at tests/lt_dlopen_a.at
tests/lt_dlopenext.at tests/ltdl-libdir.at tests/ltdl-api.at
tests/dlloader-api.at tests/loadlibrary.at tests/lalib-syntax.at
tests/resident.at tests/slist.at tests/need_lib_prefix.at tests/standalone.at
tests/subproject.at tests/nonrecursive.at tests/recursive.at tests/template.at
tests/ctor.at tests/exceptions.at tests/early-libtool.at tests/with-pic.at
tests/no-executables.at tests/deplibs-ident.at tests/configure-iface.at
tests/stresstest.at tests/cmdline_wrap.at tests/pic_flag.at tests/darwin.at
tests/dumpbin-symbols.at tests/deplibs-mingw.at tests/sysroot.at | sed
's,tests/,,g'` -o testsuite.tmp  
mv -f testsuite.tmp testsuite
abs_srcdir=`CDPATH=${ZSH_VERSION+.}:  cd .  pwd`; cd tests; 
CONFIG_SHELL=/bin/sh /bin/sh $abs_srcdir/tests/testsuite 
  MAKE=gmake CC=gcc CFLAGS=-g -O2 CPP=gcc -E CPPFLAGS=
LD=/usr/bin/ld -64 LDFLAGS= LIBS= LN_S=ln -s NM=/opt/pkg/gnu/bin/nm
-B RANLIB=ranlib AR=ar M4SH=autom4te --language=m4sh
SED=/opt/pkg/bin/gsed STRIP=strip lt_INSTALL=/opt/pkg/bin/ginstall -c
MANIFEST_TOOL=: OBJEXT=o EXEEXT= SHELL=/bin/sh CONFIG_SHELL=/bin/sh
CXX=g++ CXXFLAGS=-g -O2 CXXCPP=g++ -E F77=gfortran FFLAGS=-g -O2
FC=gfortran FCFLAGS=-g -O2 GCJ= GCJFLAGS=-g -O2
lt_cv_to_host_file_cmd=func_convert_file_noop
lt_cv_to_tool_file_cmd=func_convert_file_noop
_lt_pkgdatadir=/home/richard/src/libtool
LIBTOOLIZE=/home/richard/src/libtool/libtoolize
LIBTOOL=/home/richard/src/libtool/libtool
tst_aclocaldir=/home/richard/src/libtool/libltdl/m4 45 -d
## - ##
## GNU Libtool 2.4.2 test suite. ##
## - ##
 45: Export test ok

## - ##
## Test results. ##
## - ##

1 test was successful.

I updated this test as follows (unsure about this test on other than an
elf-based platform):

richard@devzone:~/src/libtool$ git diff tests/export.at 
diff --git a/tests/export.at b/tests/export.at
index 39adfbc..1f59fa5 100644
--- a/tests/export.at
+++ b/tests/export.at
@@ -35,7 +35,7 @@ AT_CHECK([eval `$LIBTOOL --config | sed -n
'/^archive_expsym_cmds=/,/^$/p'`
 can_hide=:
 test -s can-hide  can_hide=false
 
-LDFLAGS=$LDFLAGS -no-undefined
+#LDFLAGS=$LDFLAGS -no-undefined
 libdir=`pwd`/inst/lib
 mkdir inst inst/lib
 
@@ -170,6 +170,7 @@ do
   # case 1: shared library built from object.
   LT_AT_CHECK([eval '$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba.la
a.lo 
   -rpath $libdir' $exportsyms], [], [ignore], [ignore])
+  AT_CHECK([elfdump -d .libs/liba.so | grep SONAME],[], [ignore],
[ignore])
   AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main$EXEEXT
main.$OBJEXT liba.la],
   [], [ignore], [ignore])
   LT_AT_EXEC_CHECK([./main])

I can manually run this for C++ as follows:
richard@devzone:~/src/libtool$ gmake CC=g++ check-local TESTSUITEFLAGS=45
-d
abs_srcdir=`CDPATH=${ZSH_VERSION+.}:  cd .  pwd`; cd tests; 
CONFIG_SHELL=/bin/sh /bin/sh $abs_srcdir/tests/testsuite 
  MAKE=gmake CC=g++ CFLAGS=-g -O2 CPP=gcc -E CPPFLAGS=
LD=/usr/bin/ld -64 LDFLAGS= LIBS= LN_S=ln -s NM=/opt/pkg/gnu/bin/nm
-B RANLIB=ranlib AR=ar M4SH=autom4te --language=m4sh
SED=/opt/pkg/bin/gsed STRIP=strip lt_INSTALL=/opt/pkg/bin/ginstall -c
MANIFEST_TOOL=: OBJEXT=o EXEEXT= SHELL=/bin/sh CONFIG_SHELL=/bin/sh
CXX=g++ CXXFLAGS=-g -O2 CXXCPP=g++ -E F77=gfortran FFLAGS=-g -O2
FC=gfortran FCFLAGS=-g -O2 GCJ= GCJFLAGS=-g -O2
lt_cv_to_host_file_cmd=func_convert_file_noop
lt_cv_to_tool_file_cmd=func_convert_file_noop
_lt_pkgdatadir=/home/richard/src/libtool
LIBTOOLIZE=/home/richard/src/libtool/libtoolize
LIBTOOL=/home/richard/src/libtool/libtool
tst_aclocaldir=/home/richard/src/libtool/libltdl/m4 45 -d


## - ##
## GNU Libtool 2.4.2 test suite. ##
## - ##
 45: Export test FAILED (export.at:173)

## - ##
## Test results. ##
## - ##

ERROR: 1 test

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-12 Thread Richard PALO
Follow-up Comment #6, sr #108201 (project libtool):

And here is the diff for the proposed patch.
After cleanup and rebuilding (seemed like a zillion autoreconfs)
running the export tests as indicated (both for standard and CC=g++) are
successful.

richard@devzone:~/src/libtool$ git diff --staged
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 44e0ecf..397756f 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -6742,7 +6742,7 @@ if test $_lt_caught_CXX_error != yes; then
  if $CC --version | $GREP -v '^2.7'  /dev/null; then
_LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -nostdlib
$LDFLAGS $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags
${w
_LT_TAGVAR(archive_expsym_cmds, $1)='echo { global: 
$lib.exp~cat $export_symbols | $SED -e s/(.*)/1;/  $lib.exp~echo local:
*; };
- $CC -shared $pic_flag -nostdlib ${wl}-M $wl$lib.exp -o $lib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM
$lib.exp
+ $CC -shared $pic_flag -nostdlib ${wl}-M $wl$lib.exp ${wl}-h
$wl$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects
$compiler
 
# Commands to make compiler produce verbose output that lists
# what hidden libraries, object files and flags are used
when
@@ -6753,7 +6753,7 @@ if test $_lt_caught_CXX_error != yes; then
# platform.
_LT_TAGVAR(archive_cmds, $1)='$CC -G -nostdlib $LDFLAGS
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-h
$wl$soname
_LT_TAGVAR(archive_expsym_cmds, $1)='echo { global: 
$lib.exp~cat $export_symbols | $SED -e s/(.*)/1;/  $lib.exp~echo local:
*; };
- $CC -G -nostdlib ${wl}-M $wl$lib.exp -o $lib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags~$RM $lib.exp'
+ $CC -G -nostdlib ${wl}-M $wl$lib.exp ${wl}-h $wl$soname -o
$lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM
$lib
 
# Commands to make compiler produce verbose output that lists
# what hidden libraries, object files and flags are used
when


___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-12 Thread Richard PALO
Follow-up Comment #8, sr #108201 (project libtool):

Bob, please see comment  #5

As I indicated, local test n° 45 export.at is the existing test.

I added the following line :
AT_CHECK([elfdump -d .libs/liba.so | grep SONAME],[], [ignore], [ignore]) 

to ensure that the SONAME was being added, elfdump being available on ELF
platforms... as I mentioned, I can't answer for other platforms.

The LDFLAGS statement commented out is a misnomer, I believe, as the link
editor is not being invoked directly but indirectly via libtool and on via
$CC.  When I modified it to -Wl,--no-undefined I got a duplicate ld option
warning so I simply commented it out.
Perhaps this as well could be cleaned up to use lt_no_undefined_flag or
something like that.

Please find the git diff attached.

(file #27082)
___

Additional Item Attachment:

File name: libtool.m4.git-diffSize:1 KB


___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-12 Thread Richard PALO
Follow-up Comment #9, sr #108201 (project libtool):

BTW Bob, perhaps you didn't catch that I did a 

$git checkout  v2.4.2

since it appears much has changed since the last stable.

This is why, I believe, the tests indicate
 ## GNU Libtool 2.4.2 test suite. ## 



___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-12 Thread Richard PALO
Follow-up Comment #11, sr #108201 (project libtool):

I guess I can add the following:

1. regarding -no-undefined, when I changed this to avoid the syntax error on
solaris (which should be, for example, -Wl,--no-undefined), the linker
complained that it was a duplicate option implying, I believe, that it is by
default.

If it is a libtool directive, then it should not be in LDFLAGS which are
linker directives, it should be added independently as an additional argument
in the appropriate libtool calls.

Export.at is not the only test that uses this.

To see all that fail:

'$ gmake CC=g++ check-local'

2. as for the issues object of my libtool bug report, there is
only one... libtool omits '-Wl,-h -Wl,$soname' on solaris platforms when
CC=g++ and the link editor is solaris ld (/usr/bin/ld). 

This omits to tell the linker to add the SONAME to resulting object.

Therefore the patch submitted for libltdl/m4/libtool.m4

The test case for this is to add to 'export.at' a crucial subtest that, at
least on solaris and I presume on all ELF platforms, check that SONAME is
correctly added to the shared library/object.
(reference:news://news.gmane.org:119/20121209215323.ga...@joyent.com )

I submit that the maintainer of the test 'export.at' ensure that the test
works on all platforms.

By the way, I added only to '# case 1: shared library built from object'

Perhaps '# case 2: shared library built from convenience archive.' should also
be tested.

I leave this as well to the export.at maintainer.

Cheers 

___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-11 Thread Richard PALO
Follow-up Comment #1, sr #108201 (project libtool):

trying to bootstrap git base to provide a test case and patch proposal, but I
notice some problems already in doing after ./bootstrap  ./configure
 
gmake check syntax-check distcheck


## - ##
## Test results. ##
## - ##

151 tests behaved as expected.
17 tests were skipped.
gmake[3]: Leaving directory `/home/richard/src/libtool'
gmake[2]: Leaving directory `/home/richard/src/libtool'
gmake[1]: Leaving directory `/home/richard/src/libtool'
GFDL_version
0.12 GFDL_version
...
libtool_m4_cc_basename
sed: -e expression #1, char 86: unterminated address regex
0.03 libtool_m4_cc_basename
...
prohibit_set_dummy_without_shift
sed: -e expression #1, char 136: unterminated address regex
0.08 prohibit_set_dummy_without_shift
...
prohibit_strcmp
build-aux/ltmain.in:2824:   $SED 's/.*/  if (!strcmp
(symbol-name, )) symbol-address = (void *) ;/'  $nlistI 
$output_objdir/$my_dlsyms
maint.mk: replace strcmp calls above with STREQ/STRNEQ
gmake: *** [sc_prohibit_strcmp] Error 1

does libtool not like pkgsrc version of sed?

richard@devzone:~/src/libtool$ which sed
/opt/pkg/gnu/bin/sed
richard@devzone:~/src/libtool$ grep 'SED=' config.log
ac_cv_path_SED=/opt/pkg/bin/gsed
SED='/opt/pkg/bin/gsed'



___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-11 Thread Richard PALO
Follow-up Comment #3, sr #108201 (project libtool):

Hello Bob,

I wonder too, which is why I indicated at the end of my last comment:
 does libtool not like pkgsrc version of sed?
 
 richard@devzone:~/src/libtool$ which sed
 /opt/pkg/gnu/bin/sed
 richard@devzone:~/src/libtool$ grep 'SED=' config.log
 ac_cv_path_SED=/opt/pkg/bin/gsed
 SED='/opt/pkg/bin/gsed'


Anyway, my PATH is:
richard@devzone:~/src/libtool$ echo $PATH
/opt/pkg/sbin:/opt/pkg/bin:/opt/pkg/gnu/bin:/opt/pkg/gcc47/bin:/usr/bin:/usr/sbin:/sbin

so it has to use RPN to get to Solaris 'sed'... 

shouldn't all scripts be using more or less the same 'sed' anyway?  


I'm a bit surprised after taking a look at 'egrep sed|SED *.mk'

After looking a bit at config.log and config.status, I'm uneasy about respect
for my PATH. 

Is there a way to get this to work on OI_151a7?  

For what it is worth, I'm able to continue with pkgsrc after manually patching
/opt/pkg/bin/libtool:

richard@devzone:~$ libtool --version
ltmain.sh (GNU libtool) 2.2.6b
Written by Gordon Matzigkeit g...@gnu.ai.mit.edu, 1996

Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
richard@devzone:~$ pkgdiff /opt/pkg/bin/libtool
$NetBSD$

--- /opt/pkg/bin/libtool.orig   2012-12-11 12:43:45.0 +
+++ /opt/pkg/bin/libtool
@@ -8967,7 +8967,7 @@ old_archive_from_expsyms_cmds=
 # Commands used to build a shared archive.
 archive_cmds=$CC -shared -nostdlib $LDFLAGS $predep_objects $libobjs
$deplibs $postdep_objects $compiler_flags ${wl}-h $wl$soname -o $lib
 archive_expsym_cmds=echo \{ global:\  $lib.exp~cat $export_symbols | $SED
-e \s/\\(.*\\)/\\1;/\  $lib.exp~echo \local: *; };\  $lib.exp~
- $CC -shared -nostdlib ${wl}-M $wl$lib.exp -o $lib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM
$lib.exp
+ $CC -shared -nostdlib ${wl}-M $wl$lib.exp ${wl}-h $wl$soname
-o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM
$lib.exp
 
 # Commands used to build a loadable module if different from building
 # a shared archive.


It's a very short term remedy but hopefully we can rapidly get libtool, and
then pkgsrc updated.

___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-11 Thread Richard PALO
Follow-up Comment #4, sr #108201 (project libtool):

I was working off of master. With git blame I noticed that the strcmp problem
was introduced recently, so I'm trying over after git checkout v2.4.2, which
is the latest tarball version I've tested with pkgsrc.

HEAD is now at fdb4c54... Release 2.4.2

hopefully it'll go a bit cleaner.

___

Reply to this item at:

  http://savannah.gnu.org/support/?108201

___
  Message posté via/par Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool


[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

2012-12-10 Thread Richard PALO
URL:
  http://savannah.gnu.org/support/?108201

 Summary: libtool problems with -export-symbols-regex on
solaris with gcc-4.7.x
 Project: GNU Libtool
Submitted by: risto3
Submitted on: lun. 10 déc. 2012 13:58:02 GMT
Category: None
Priority: 5 - Normal
Severity: 4 - Important
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: *BSD

___

Details:

(I put *BSD because SunOS not available)

In trying to build rarian-0.8.1, it appears that the shared library
(librarian.so) is not built correctly.

I have I isolated the problem to the following statement in Makefile.am

librarian_la_LDFLAGS = -export-symbols-regex ^rrn_.*

Here is the resulting libtool output for this command:
/bin/sh ../libtool --tag=CXX   --mode=link g++  -g -O2 -export-symbols-regex
^rrn_.*  -o librarian.la -rpath /usr/local/lib librarian_la-rarian-main.lo
librarian_la-rarian-reg-utils.lo librarian_la-rarian-language.lo
librarian_la-rarian-utils.lo librarian_la-rarian-info.lo
librarian_la-rarian-man.lo rarian-omf.lo tinyxml.lo tinyxmlparser.lo
tinystr.lo tinyxmlerror.lo

libtool: link: rm -fr  .libs/librarian.a .libs/librarian.exp
.libs/librarian.la .libs/librarian.lai .libs/librarian.so .libs/librarian.so.0
.libs/librarian.so.0.0.0
libtool: link: /opt/pkg/gnu/bin/nm -B  .libs/librarian_la-rarian-main.o
.libs/librarian_la-rarian-reg-utils.o .libs/librarian_la-rarian-language.o
.libs/librarian_la-rarian-utils.o .libs/librarian_la-rarian-info.o
.libs/librarian_la-rarian-man.o .libs/rarian-omf.o .libs/tinyxml.o
.libs/tinyxmlparser.o .libs/tinystr.o .libs/tinyxmlerror.o   | sed -n -e
's/^.*[  ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][  
]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1
\2 \2/p' | sed '/ __gnu_lto/d' | /opt/pkg/bin/gsed 's/.* //' | sort | uniq 
.libs/librarian.exp
libtool: link: /opt/pkg/bin/ggrep -E -e ^rrn_.* .libs/librarian.exp 
.libs/librarian.expT
libtool: link: mv -f .libs/librarian.expT .libs/librarian.exp
libtool: link: echo { global:  .libs/librarian.so.0.0.0.exp
libtool: link: cat .libs/librarian.exp | /opt/pkg/bin/gsed -e s/\(.*\)/\1;/
 .libs/librarian.so.0.0.0.exp
libtool: link: echo local: *; };  .libs/librarian.so.0.0.0.exp
libtool: link:  g++ -shared  -fPIC -DPIC -nostdlib -Wl,-M
-Wl,.libs/librarian.so.0.0.0.exp -o .libs/librarian.so.0.0.0
/usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o
/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/crtbegin.o 
.libs/librarian_la-rarian-main.o .libs/librarian_la-rarian-reg-utils.o
.libs/librarian_la-rarian-language.o .libs/librarian_la-rarian-utils.o
.libs/librarian_la-rarian-info.o .libs/librarian_la-rarian-man.o
.libs/rarian-omf.o .libs/tinyxml.o .libs/tinyxmlparser.o .libs/tinystr.o
.libs/tinyxmlerror.o   -L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/../../../../x86_64-sun-solaris2.11/lib/amd64
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/../../../amd64
-L/lib/amd64 -L/usr/lib/amd64
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/../../../../x86_64-sun-solaris2.11/lib
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/../../.. -lstdc++ -lm
-lc -lgcc_s /opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/crtend.o
/usr/lib/amd64/crtn.o  -O2  
libtool: link: rm -f .libs/librarian.so.0.0.0.exp
libtool: link: (cd .libs  rm -f librarian.so.0  ln -s
librarian.so.0.0.0 librarian.so.0)
libtool: link: (cd .libs  rm -f librarian.so  ln -s
librarian.so.0.0.0 librarian.so)
libtool: link: ar cru .libs/librarian.a  librarian_la-rarian-main.o
librarian_la-rarian-reg-utils.o librarian_la-rarian-language.o
librarian_la-rarian-utils.o librarian_la-rarian-info.o
librarian_la-rarian-man.o rarian-omf.o tinyxml.o tinyxmlparser.o tinystr.o
tinyxmlerror.o
libtool: link: ranlib .libs/librarian.a
libtool: link: ( cd .libs  rm -f librarian.la  ln -s ../librarian.la
librarian.la )

If I suppress the -export-symbols-regex ^rrn_.*, the following is output:
libtool: link: rm -fr  .libs/librarian.a .libs/librarian.exp
.libs/librarian.la .libs/librarian.lai .libs/librarian.so .libs/librarian.so.0
.libs/librarian.so.0.0.0
libtool: link: g++ -shared  -fPIC -DPIC -nostdlib  /usr/lib/amd64/crti.o
/usr/lib/amd64/values-Xa.o
/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/crtbegin.o 
.libs/librarian_la-rarian-main.o .libs/librarian_la-rarian-reg-utils.o
.libs/librarian_la-rarian-language.o .libs/librarian_la-rarian-utils.o
.libs/librarian_la-rarian-info.o .libs/librarian_la-rarian-man.o
.libs/rarian-omf.o .libs/tinyxml.o .libs/tinyxmlparser.o .libs/tinystr.o
.libs/tinyxmlerror.o   -L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2
-L/opt/pkg/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.2/../../../../x86_64-sun-solaris2.11/lib/amd64

Re: no .pc file

2012-10-26 Thread Richard Purdie
On Fri, 2012-10-26 at 13:27 -0500, Bob Friesenhahn wrote:
 On Fri, 26 Oct 2012, Yaroslav Bulatov wrote:
 
  Oops my badthat was a bad paste from some auto-generated code.
 
  This is basically a modified version of .pc file I get when building
  zlib. Not sure how useful this is because you need to update prefix
  in this file manually each time you rebuild libtool. Ideally the .pc
  file would be generated automatically by configure/make
 
 If it is not clear, package config files are operating system and/or 
 operating system distribution and/or operating system release version 
 specific.  One reason for this is that each operating system 
 distribution uses its own names for pkg-config package definitions. 
 Using zlib as an example is not useful since zlib does not depend on 
 any other packages.  Most packages depend on other packages and so 
 there is an OS-distribution (or even site-specific) list of packages 
 that this package depends on.
 
 While many packages do produce sample pkg-config files (based on 
 guess-work or assumption of a partiticular OS distribuiton), it is 
 common practice for the default offering to be modified by the OS 
 package distribution maintainer because the OS uses a different name 
 for a similar thing.
 
 Being intended for portable software, libtool does not concern itself 
 with a hand-edited/non-portable framework like pkg-config.

As I understand it, the .pc files use their own namespace so once a
given piece of software has chosen its naming, other things can depend
on it using that name space and it doesn't matter about the OS
distribution or OS version used. This is a clear incentive to maintain
the .pc file with the software so that there is one common naming used,
at least in pkg-config space. There is no connection to the package
management namespace which is totally separate.

This assumes that people use some kind of common sense when choosing
namespace but other than that it seems to work well.

As one of the people looking after the Yocto Project (which includes an
build system targeted at embedded devices), I have to say I see less
problems with pkg-config than with libtool and I'm once again being
asked to remove all .la files as a policy decision due to them causing
more problems than they seem to solve in a cross environment :(. I'm
running out of arguments against this, not least as I couldn't get any
response to the libtool sysroot problems I reported a while back.

Cheers,

Richard


___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Libtool sysroot RPATH problems

2011-01-13 Thread Richard Purdie
Hi Ralf,

Thanks for the reply.

On Thu, 2011-01-13 at 08:24 +0100, Ralf Wildenhues wrote:
 * Richard Purdie wrote on Wed, Jan 12, 2011 at 12:06:13AM CET:
  Firstly, for the first time ever for us, it appears libtool is no longer
  relinking our libraries at install time.
 
 That's weird, I don't think the sysroot feature should've caused this
 change.  Not quite sure though.
 
  This is welcome as we're cross
  compiling to a sysroot and we'd never want to actually run them in situ
  so this could probably save us some build time. It does however mean we
  never go for a relink step so we're hitting codepaths and issues that
  I've never seen. For reference, we always used to set installed=no in
  our staged libraries prior to sysroot support since this let us hack
  around the lack of sysroot support easier.
  
  Anyhow, the problem I'm seeing is that the final library has an RPATH
  including the sysroot prefix when make is calling libtool with
  -rpath /usr/lib at link time. I looked at the code in ltmain.m4sh
  starting at line 7240 (see the end of the email for a quotation) and
  firstly, I don't understand why the func_replace_sysroot call is inside
  the $hardcode_libdir_separator test? Surely it should be outside it and
  happen whenever $hardcode_libdir_flag_spec is set?

Firstly let me be upfront and clear, I do have some patches applied on
top of libtool 2.4 to address some problems. These are:

http://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/libtool/libtool/rename-with-sysroot.patch?h=sgarman/libtool-sysroot
(to stop conflicts with gcc/binutils configure options)
http://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/libtool/libtool/prefix.patch?h=sgarman/libtool-sysroot
(renamed libtool to TARGET_PREFIX-libtool, which is mainly useful to
detect when our libtool patches aren't being noticed)
http://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/libtool/libtool/trailingslash.patch?h=sgarman/libtool-sysroot
(a path comparison problem I never did get to the bottom of to report
properly but the fix appears harmless)
http://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/libtool/libtool/use-sysroot-in-libpath.patch?h=sgarman/libtool-sysroot
(a sysroot fix I believe is in libtool git now)

I don't believe any of these are contributing to the issues I'm seeing
though.

http://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/libtool/libtool/fix-final-rpath.patch?h=sgarman/libtool-sysroot
is a WIP patch which addresses some of the problems I refer to in this
email thread. Its not applied for the tests below.

 Please show the --mode={link,install} commands plus all of their output,
 also './libtool --config'.  Please also show how exactly you invoke
 configure.  Thanks.

A link command and output showing the problem:

/bin/sh ./i586-poky-linux-libtool --tag=CC   --mode=link i586-poky-linux-gcc 
-march=i586 
--sysroot=/media/build2/builds/rptest/b2/tmp/sysroots/i586-poky-linux  
-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb 
-feliminate-unused-debug-types -no-undefined -export-dynamic -version-number 
0:44:0 -Wl,--version-script=libpng.vers  -Wl,-O1 -Wl,--hash-style=gnu 
-Wl,--as-needed -o libpng12.la -rpath /usr/lib libpng12_la-png.lo 
libpng12_la-pngset.lo libpng12_la-pngget.lo libpng12_la-pngrutil.lo 
libpng12_la-pngtrans.lo libpng12_la-pngwutil.lo libpng12_la-pngread.lo 
libpng12_la-pngrio.lo libpng12_la-pngwio.lo libpng12_la-pngwrite.lo 
libpng12_la-pngrtran.lo libpng12_la-pngwtran.lo libpng12_la-pngmem.lo 
libpng12_la-pngerror.lo libpng12_la-pngpread.lo  -lz -lm 
i586-poky-linux-libtool: link: i586-poky-linux-gcc -march=i586 
--sysroot=/media/build2/builds/rptest/b2/tmp/sysroots/i586-poky-linux -shared  
-fPIC -DPIC  .libs/libpng12_la-png.o .libs/libpng12_la-pngset.o 
.libs/libpng12_la-pngget.o .libs/libpng12_la-pngrutil.o 
.libs/libpng12_la-pngtrans.o .libs/libpng12_la-pngwutil.o 
.libs/libpng12_la-pngread.o .libs/libpng12_la-pngrio.o 
.libs/libpng12_la-pngwio.o .libs/libpng12_la-pngwrite.o 
.libs/libpng12_la-pngrtran.o .libs/libpng12_la-pngwtran.o 
.libs/libpng12_la-pngmem.o .libs/libpng12_la-pngerror.o 
.libs/libpng12_la-pngpread.o   -Wl,-rpath 
-Wl,/media/build2/builds/rptest/b2/tmp/sysroots/i586-poky-linux/usr/lib 
/media/build2/builds/rptest/b2/tmp/sysroots/i586-poky-linux/usr/lib/libz.so -lm 
 -march=i586 
--sysroot=/media/build2/builds/rptest/b2/tmp/sysroots/i586-poky-linux -O2 
-Wl,--version-script=libpng.vers -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed   
-Wl,-soname -Wl,libpng12.so.0 -o .libs/libpng12.so.0.44.0
i586-poky-linux-libtool: link: (cd .libs  rm -f libpng12.so.0  ln -s 
libpng12.so.0.44.0 libpng12.so.0)
i586-poky-linux-libtool: link: (cd .libs  rm -f libpng12.so  ln -s 
libpng12.so.0.44.0 libpng12.so)
mv -f .deps/libpng_la-pngwtran.Tpo .deps/libpng_la-pngwtran.Plo
i586-poky-linux-libtool: link: i586-poky-linux-ar cru .libs/libpng12

Libtool sysroot RPATH problems

2011-01-11 Thread Richard Purdie
Hi,

I work on OpenEmbedded/Poky and we're been experimenting with the recent
libtool sysroot support. To say I'm pleased to have this is an
understatement! We're having a few problems around incorrect RPATHs
being encoded into libraries however.

Firstly, for the first time ever for us, it appears libtool is no longer
relinking our libraries at install time. This is welcome as we're cross
compiling to a sysroot and we'd never want to actually run them in situ
so this could probably save us some build time. It does however mean we
never go for a relink step so we're hitting codepaths and issues that
I've never seen. For reference, we always used to set installed=no in
our staged libraries prior to sysroot support since this let us hack
around the lack of sysroot support easier.

Anyhow, the problem I'm seeing is that the final library has an RPATH
including the sysroot prefix when make is calling libtool with
-rpath /usr/lib at link time. I looked at the code in ltmain.m4sh
starting at line 7240 (see the end of the email for a quotation) and
firstly, I don't understand why the func_replace_sysroot call is inside
the $hardcode_libdir_separator test? Surely it should be outside it and
happen whenever $hardcode_libdir_flag_spec is set?

Changing that helps a bit and I end up with an RPATH of =/usr/lib so
the sysroot prefix is gone but the = is there. I suspect that isn't
valid so I added the following code after the func_replace_sysroot call

func_stripname '=' '' $libdir
libdir=$func_stripname_result

and then I get an RPATH of /usr/lib which is ok to a point.

Of course this is listed in $sys_lib_dlsearch_path_spec so shouldn't be
getting added at all. Its coming to this function via $compile_rpath
which is being set around line 5939 which in turn is coming from absdir.
absdir is being compared against $sys_lib_dlsearch_path_spec but without
adding/removing any sysroot prefixes.

I'd really therefore like to ask what behaviour to be expecting from
libtool before I try and write patches to fix any of this. To summarise
some of my questions:

a) If I'm using a sysroot can I expect to install without a relink step 
   (I hope so!)
b) I couldn't see a function to add/prepend a sysroot without a = in 
   there. I assume given these usecases we should add one?
c) An RPATH starting with an = is invalid, correct?
d) Should the absdir comparisions with sys_lib_dlsearch_path_spec have 
   the sysroot stripped? Are there other rpath variables that need this 
   treatment when comparing to sys_lib_dlsearch_path_spec?
e) The sysroot treatment should apply whenever 
   $hardcode_libdir_flag_spec is set and not on 
   $hardcode_libdir_separator?

If someone could explain the correct behaviour I might be able to come
up with some patches to help fix things! :)

Cheers,

Richard

http://git.savannah.gnu.org/cgit/libtool.git/tree/libltdl/config/ltmain.m4sh?id=9167aecabd12c5afe7a65d45dc73f8c92ab42f05
line 7240:
  # Test again, we may have decided not to build it any more
  if test $build_libtool_libs = yes; then
# Remove ${wl} instances when linking with ld.
# FIXME: should test the right _cmds variable.
case $archive_cmds in
  *\$LD\ *) wl= ;;
esac
if test $hardcode_into_libs = yes; then
  # Hardcode the library paths
  hardcode_libdirs=
  dep_rpath=
  rpath=$finalize_rpath
  test $opt_mode != relink  rpath=$compile_rpath$rpath
  for libdir in $rpath; do
if test -n $hardcode_libdir_flag_spec; then
  if test -n $hardcode_libdir_separator; then
func_replace_sysroot $libdir
libdir=$func_replace_sysroot_result
if test -z $hardcode_libdirs; then
  hardcode_libdirs=$libdir
line 5929:
  if test $linkmode = lib 
 test $hardcode_into_libs = yes; then
# Hardcode the library path.
# Skip directories that are in the system default run-time
# search path.
case  $sys_lib_dlsearch_path  in
* $absdir *) ;;
*)
  case $compile_rpath  in
  * $absdir *) ;;
  *) func_append compile_rpath  $absdir ;;
  esac
  ;;
esac


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Issues w/ relink and cross-compilation

2010-07-12 Thread Richard Purdie
Hi,

I've spoken about this in the past but it looks like I should mention it
again. I do extensive cross compiling of the entire Linux software stack
using OpenEmbedded and Poky (I maintain the latter). We have cross
compiling working with libtool with a variety of workarounds. This
mainly consists of the following simple patch to libtool itself:

http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/libtool/libtool/cross_compile.patch

and then manipulation of the .la files with sed if we ever want to move
the sysroot directory, or use the .la files on the target device.

There are a couple of other patches we use. One is to allow multiple
libtool scripts to live in the same place by adding a cross prefix to
the tool name:

http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/libtool/libtool/prefix.patch

This patch also allows us to tell when the wrong (unpatched) libtool
is being used. 

The final patch we're currently applying is probably a bug in libtool:

http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/libtool/libtool/trailingslash.patch

where a directory comparison was failing as one variable ended in a
slash and the other did not. We're fixing this by stripping any slash
off both options (the patch is pending an update to do this). I haven't
isolated a proper test case to be able to submit this one as a proper
bug yet though.

Longer term I'm still hoping we'll see sysroot support in libtool and I
may even find some time to start the ball rolling on patches eventually
but I'm not going to get to that soon, much as I wish it were otherwise.

Cheers,

Richard


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO

2010-04-01 Thread Richard Guenther
On Wed, Mar 31, 2010 at 8:33 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
 * Richard Guenther wrote on Wed, Mar 31, 2010 at 11:02:39AM CEST:
 On Tue, Mar 30, 2010 at 8:52 PM, Ralf Wildenhues wrote:
  1) Autoconf-generated configure tests often fake the prototype of some
  function; e.g., AC_CHECK_FUNC([func]) uses
   char func();
 
  and tries to link that.  Using this is undefined according to C99, if
  func has a different actual prototype, and when all system libraries are
  LTO'ed, gcc -flto may even detect this kind of inconsistency and could
  act accordingly (nasal demons and such).

 I suppose autoconf cannot do this for C++ functions then, because
 of mangling issues?

 Correct.  For C++ libraries, it is more typical to just write a complete
 test source and AC_COMPILE_IFELSE or AC_LINK_IFELSE it.

 FWIW, there is an Autoconf patch pending to allow AC_CHECK_DECL with
 declarations given by the user (in order to support overloaded
 basename, for example).

 Note that the only thing GCC with LTO might do here is to issue
 a diagnostic (which of course might confuse the configure script),
 but we cannot really reject such programs (as such errors are
 unfortunately very common) and thus defer any problems to
 link- and/or runtime.

 That's almost exactly the kind of semantics I would like to see.
 Can we get this documented in the manual?  Something like this.
 Note that it would explicitly contradict one of the design goals
 listed in lto.pdf, which is that conflicting declarations might
 provoke an error; so really GCC developers should make a conscious
 design decision here.


        * doc/invoke.texi (Optimize Options): Document that LTO
        won't remove object access purely due to incompatible
        declarations.

 diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
 index 2226cad..85f9c5f 100644
 --- a/gcc/doc/invoke.texi
 +++ b/gcc/doc/invoke.texi
 @@ -7294,6 +7294,12 @@ regular (non-LTO) compilation.  This means that if 
 your build process
  was mixing languages before, all you need to add is @option{-flto} to
  all the compile and link commands.

 +If LTO encounters objects with C linkage declared with incompatible
 +types in separate translation units to be linked together (undefined
 +behavior according to ISO C99 6.2.7), it might produce a warning, but
 +this fact alone will not cause an access to an object to be optimized
 +away.
 +
  If object files containing GIMPLE bytecode are stored in a library
  archive, say @file{libfoo.a}, it is possible to extract and use them
  in an LTO link if you are using @command{gold} as the linker (which,

Well, the wording is almost ok, but

+behavior according to ISO C99 6.2.7), a non-fatal diagnostic may
be issued.  The behavior is still undefined at runtime.

would be more precise.  Especially accesses to conflicting
declarations can end up being optimized away if there's unfortunate
inlining so that for example with

t1.c
float f;
t2.c
int f;

 f[int] = 1.0;
 f[float] = 1;

GCC can end up re-ordering the stores to f and thus effectively
optimize away one or the other.

With function calls there's no such issue, but argument passing
might be completely off (obviously).

Richard.


 (In practice, Autoconf does not support -Werror at configure time; this
 issue only reinforces that.)

  b) The symbols 'func' and 'variable' likely have the wrong prototypes,
  i.e., elsewhere, they might be declared as
 
   void func(int, double);
   double variable[42];
 
  instead.  I haven't come across any actual issues with this yet, except
  now LTO may rightfully complain about it.

 Same issue as above.  We try to handle it - there might be bugs
 in the current implementation of LTO though.

 Bugs are no problem as long as they are acknowledged as such.  I desire
 future compatibility, i.e., being fairly certain autotools don't regress
 just because of a good improvement in some other tool.  Dealing with
 existing cruft is abundant in autotools.

  Question is, what can we do about this?  We could ensure to never pass
  -flto or -fwhopr to the compilation of the libtool symfile object, and
  remove it from some or all link tests done in configure.  That's ugly.
  Would that even be sufficient though?  Conversely, would GCC developers
  be willing to agree that, when GCC detects such inconsistencies, it
  wouldn't take adverse advantage of it (e.g., by turning off LTO in this
  case, or similar)?
 
  Other possibilities for Autoconf would be to work toward a new set of
  checking macros (or extensions of current one) where the configure.ac
  author passes a full prototype for each function to check (Autoconf
  could keep a list of known prototypes for often-checked functions).
  I'm not sure how to fix the libtool symfile in a C99-conforming way.

 I'd say wait and see.  What would be nice to have is a few testcases
 that cover the autoconf cases in the GCC testsuite (feel free to
 just file them into bugzilla).

 I have been doing just

Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO

2010-03-31 Thread Richard Guenther
On Tue, Mar 30, 2010 at 8:52 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
 Hello gcc and libtool lists,

 Summary: both Autoconf-generated configure tests as well as some Libtool
 construct invoke undefined behavior.  Question is how to deal with it,
 and whether GCC, as QoI, may want to define behavior in these cases.


 1) Autoconf-generated configure tests often fake the prototype of some
 function; e.g., AC_CHECK_FUNC([func]) uses
  char func();

 and tries to link that.  Using this is undefined according to C99, if
 func has a different actual prototype, and when all system libraries are
 LTO'ed, gcc -flto may even detect this kind of inconsistency and could
 act accordingly (nasal demons and such).

I suppose autoconf cannot do this for C++ functions then, because
of mangling issues?

Note that the only thing GCC with LTO might do here is to issue
a diagnostic (which of course might confuse the configure script),
but we cannot really reject such programs (as such errors are
unfortunately very common) and thus defer any problems to
link- and/or runtime.

 2) libtool has a feature that makes it extract symbol lists from
 objects and turn them into fake declarations and function/object
 pointers: fake static preloaded modules.

 It currently works by running nm or a similar tool over the object, then
 converting the output with a couple of sed script or so
 (global_symbol_pipe, global_symbol_to_cdecl, and a couple more) to a
 synthesized extra source file that then contains code like this:

 extern int func();
 extern char variable;

 typedef struct {
  const char *name;
  void *address;
 } lt_dlsymlist;

 extern const lt_dlsymlist
 lt__PROGRAM__LTX_preloaded_symbols[];
 const lt_dlsymlist
 lt__PROGRAM__LTX_preloaded_symbols[] =
 {  { @PROGRAM@, (void *) 0 },
  {func, (void *) func},
  {variable, (void *) variable},
  {0, (void *) 0}
 };

 This is invoking undefined behavior in a couple of respects:

 a) Pointers to functions are stored in pointer-to-void variables.
 This could be fixed with an incompatible API change to using a union of
 object and function pointer, I guess.

 b) The symbols 'func' and 'variable' likely have the wrong prototypes,
 i.e., elsewhere, they might be declared as

  void func(int, double);
  double variable[42];

 instead.  I haven't come across any actual issues with this yet, except
 now LTO may rightfully complain about it.

Same issue as above.  We try to handle it - there might be bugs
in the current implementation of LTO though.

 Question is, what can we do about this?  We could ensure to never pass
 -flto or -fwhopr to the compilation of the libtool symfile object, and
 remove it from some or all link tests done in configure.  That's ugly.
 Would that even be sufficient though?  Conversely, would GCC developers
 be willing to agree that, when GCC detects such inconsistencies, it
 wouldn't take adverse advantage of it (e.g., by turning off LTO in this
 case, or similar)?

 Other possibilities for Autoconf would be to work toward a new set of
 checking macros (or extensions of current one) where the configure.ac
 author passes a full prototype for each function to check (Autoconf
 could keep a list of known prototypes for often-checked functions).
 I'm not sure how to fix the libtool symfile in a C99-conforming way.

I'd say wait and see.  What would be nice to have is a few testcases
that cover the autoconf cases in the GCC testsuite (feel free to
just file them into bugzilla).  We really do not want to break
working setups with LTO - any fancy ODR violation diagnostics
should IMHO be optional, only things that LTO does not get
correct are currently diagnosed IIRC.

Thanks,
Richard.

 Thanks for reading this far.

 Cheers,
 Ralf



___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Issue with libtool when cross-compiling

2010-02-12 Thread Richard Purdie
On Fri, 2010-02-12 at 16:34 +0100, Thomas Petazzoni wrote:
 I'm a contributor to the Buildroot project (http://www.buildroot.org),
 a build system for embedded Linux systems. We integrate many packages
 in order to ease their cross-compilation.
 
 I'm facing an issue with several packages where libtool wants to link
 against libraries of the host (in /usr/lib), and I don't know what
 is happening. It is very likely a problem in the environment variables
 or the options we pass to the configure script, but I'm unable to find
 where the problem is, and thought that libtool experts might have an
 idea on what's going on.

libtool has known cross compile issues and doesn't get on well with
sysroots. 

I maintain the OpenEmbedded libtool patch set which at least lets us
work around the worst libtool issues. The main patch is:

http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/libtool/libtool-2.2.6/cross_compile.patch

and there is a bugfix I've been meaning to look at in more detail which
became neccessary with recent autoconf/automake versions:

http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/libtool/libtool-2.2.6/trailingslash.patch

where a trailing slash on paths causes a string comparison to fail. We
also apply: 

http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/libtool/libtool-2.2.6/prefix.patch

which renames libtool and allows us to easily tell when the wrong
(unpatched) libtool is being used.

There are other workarounds we have to apply after installing packages,
particularly modifying the .la files to be uninstalled to get the
sysroot to work properly. I'd love to teach libtool about sysroots and
make it work properly but as yet have never had the time to look into
it.

Cheers,

Richard




___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Issue with libtool when cross-compiling

2010-02-12 Thread Richard Purdie
On Fri, 2010-02-12 at 19:34 +0100, Thomas Petazzoni wrote:
 I suppose you apply these modifications to a libtool that you are
 compiling. However, libtool is typically already embedded in each
 upstream tarball. Do you run autoreconf on all packages, so that a
 newer libtool script gets generated (autoreconf-ing each package takes a
 lot of time) ? Do you somehow replace the provided libtool by a fixed
 one ?
 
 Moreover, some packages use libtool 1.5.x and some newer packages use
 libtool 2.2.x. How do you handle this version difference ?

Due to exactly this kind of problem OpenEmbedded generally autoreconfs
all sources.

  There are other workarounds we have to apply after installing
  packages, particularly modifying the .la files to be uninstalled to
  get the sysroot to work properly.
 
 « to be uninstalled » ?

Set installed=no in the .la files.

 In Buildroot, we already modify the libdir='' in all the .la files so
 that they refer to the sysroot instead of /usr/lib.

We change the dependency_libs line. The libdir line refers to the final
install location and /usr/lib is in fact valid there.

 If possible, could you point me to the location in OpenEmbedded where
 libtool is handled ? I already had a look at your patches, but don't
 understand how you re-generate the libtool script inside the different
 upstream packages.

meta/classes/autoconf.bbclass has the autoreconf code

meta/classes/base.bbclass has the .la file manipulation.

What I find frustrating is that buildroot is playing catchup to OE these
days. By the time you make all the improvements to buildroot, you end up
with OE.

What would it take to get the buildroot people using OE and focusing
effort to new problems, not ones already at least partially solved?

I'd love to see a kconfig wrapper to OE for example...

Cheers,

Richard





___
http://lists.gnu.org/mailman/listinfo/libtool


Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

2009-08-25 Thread Richard Purdie
On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote:
 * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST:
  On Tue, 25 Aug 2009, Anssi Hannula wrote:
  
  I think the proper way to solve this is to not link to dependency_libs
  when linking dynamically on systems where it is not needed to link to
  those. I haven't seen any correctly working patches that implement this.
  
  Relying on the OS's implicit dependency features seems to be an
  approach which is fraught with peril.
 
 With GNU/Linux, and libraries all being in directories searched by
 default by both the link editor and the runtime linker, the problems
 are fairly limited.  IIRC Debian requires that you link directly against
 all libraries that you require directly.
 
 The problems start as soon as you link (directly or indirectly) against
 libraries in directories not searched by default.  IOW: typically
 anything not provided by a properly packaged Debian package, installed
 by the user or the system maintainer.

Surely at least on Linux the -rpath linker option would be a much better
way to solve this?

Linux does seem to have good dynamic linker support and its a shame
libtool effectively drags it down to a lower common denominator of other
platforms with worse support.

Cheers,

Richard

-- 
Richard Purdie
Intel Open Source Technology Centre



___
http://lists.gnu.org/mailman/listinfo/libtool


Re: [PATCH] Build AIX shared libraries with binutils 2.19.50+

2009-06-23 Thread Richard Sandiford
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
 sorry for the long delay.  Apparently the 4.3.3 system has flaky
 hardware; anyway I don't trust its results any more.

 I've now pushed your two proposed patches, added a small NEWS entry to
 the first, and added you to THANKS.

Great!  Thanks for all your help.  And sorry for the long time in
replying, have been away for the last 2 weeks.

Richard




Re: [PATCH] Fix GNU nm invocation for AIX

2009-05-12 Thread Richard Sandiford
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
 Can I just ping this?

 Sure.  I think that I will get to it (both patches) this weekend.
 Basically I will do the testing myself on 5.3, 4.3.3, and maybe 5.1.  If
 somebody beats me to this, and is able to post testsuite.log files (even
 sanitized or anonymized would be ok), then be my guest.

Great, thanks.  In that case, sorry for the ping: I hadn't realised you
had access to these.

Richard




Re: [PATCH] Fix GNU nm invocation for AIX

2009-05-08 Thread Richard Sandiford
[off-list]

Hi Ralf,

Can I just ping this?

To recap, the aim of the submission was to get binutils on AIX as good
as native tools on AIX.  I think I've done that.  It'd be nice if we had
zero libtool failures for native tools to begin with, but I'm afraid
I really don't have time to work on that myself.

Richard

Richard Sandiford richa...@transitive.com writes:
 Ralf Wildenhues ralf.wildenh...@gmx.de writes:
 * Richard Sandiford wrote on Fri, Apr 24, 2009 at 06:35:20PM CEST:
 Ralf Wildenhues ralf.wildenh...@gmx.de writes:
  * Richard Sandiford wrote on Mon, Mar 16, 2009 at 10:53:23AM CET:
  AIX nm lists weak defined symbols like any other global symbol,
  whereas GNU nm lists them as W.  The export_symbols_cmds for
  GNU nm on AIX should therefore look for W in addition to the
  other codes.
  
  Tested using GCC.  Please install if OK.
 
  This patch is also ok if you state how you tested resp. show Libtool
  testsuite results.
 
 Thanks.  Here are the results, after the updates described in my
 last message.  I get the same results using the preinstalled GCC
 with native tools.

 Thanks.  Can you please also send the tests/testsuite.log file
 (preferably bzip2'ed or gzip'ed), that makes analyzing the failures
 much easier.

 Sorry, but I don't think I'm allowed to send out things like that.
 The output before each failure is the same as it was with the native
 tools and preinstalled gcc though.

 Richard




Re: [PATCH] Fix GNU nm invocation for AIX

2009-04-25 Thread Richard Sandiford
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
 * Richard Sandiford wrote on Fri, Apr 24, 2009 at 06:35:20PM CEST:
 Ralf Wildenhues ralf.wildenh...@gmx.de writes:
  * Richard Sandiford wrote on Mon, Mar 16, 2009 at 10:53:23AM CET:
  AIX nm lists weak defined symbols like any other global symbol,
  whereas GNU nm lists them as W.  The export_symbols_cmds for
  GNU nm on AIX should therefore look for W in addition to the
  other codes.
  
  Tested using GCC.  Please install if OK.
 
  This patch is also ok if you state how you tested resp. show Libtool
  testsuite results.
 
 Thanks.  Here are the results, after the updates described in my
 last message.  I get the same results using the preinstalled GCC
 with native tools.

 Thanks.  Can you please also send the tests/testsuite.log file
 (preferably bzip2'ed or gzip'ed), that makes analyzing the failures
 much easier.

Sorry, but I don't think I'm allowed to send out things like that.
The output before each failure is the same as it was with the native
tools and preinstalled gcc though.

Richard




Re: [PATCH] Build AIX shared libraries with binutils 2.19.50+

2009-04-24 Thread Richard Sandiford
Hi Ralf,

Thanks for the review, and sorry for the long time it's taken to reply.

Ralf Wildenhues ralf.wildenh...@gmx.de writes:
 * Richard Sandiford wrote on Mon, Mar 16, 2009 at 10:49:17AM CET:
 If you try to configure libtool to build shared libraries on AIX,
 it prints the following message when using GNU ld:
 
 *** Warning: the GNU linker, at least up to release 2.9.1, is reported
 *** to be unable to reliably create shared libraries on AIX.
 *** Therefore, libtool is disabling shared libraries support.  If you
 *** really care for shared libraries, you may want to modify your PATH
 *** so that a non-GNU linker is found, and then restart.
 
 binutils 2.19 doesn't work either, so the patch below updates the
 version number.  However, a series of AIX patches were applied to
 binutils CVS this weekend:
 
   http://sourceware.org/ml/binutils/2009-03/msg00172.html

 For those interested in reading the whole thread, this is:
 http://thread.gmane.org/gmane.comp.gnu.binutils/40460

 Do they target AIX 6 only, or earlier versions as well?
 Which versions were they tested with?

They effectively target all versions, in that almost all the patches
fix generic AIX problems rather than AIX-6-specific problems.  Only one
patch was actually specific to AIX 6, and it simply added support for
the target triplet.  Binutils doesn't implement any features that
are specific to AIX 6.

The patches were tested on AIX 6.  I don't have access to other versions.

 We have users going back to 4.3.3 IIRC.  If the new support doesn't go
 back all that far, we should only enable it for as far back as is safe.

Understood.  It's probably best if I leave that call up to you.  On the
one hand, I think there's a good chance that the binutils patches will
work on AIX 5.2+, since like I say, binutils doesn't really implement
any features specific to AIX 6 per se.  If that turns out not to be
true for any reason, I'd be happy to look at the bug reports.  It might
therefore seem overly hash to stop AIX 5.2 users from even trying to use
binutils to build shared libraries.

  (The same offer extends to 4.3.3 btw, but the impact of the change
  is harder to predict there, since the OS doesn't have weak support.)

On the other hand, I suppose it will take a long time for this libtool
change to filter to some packages anyway, so in practice, anyone interested
in using binutils with AIX will have to use a locally-updated libtool.
They could easily modify the libtool patch to do what they want.

 One fix would be to add real GNU ld support if the linker is
 new enough.  However, GNU ld tries to be command-line compatible
 with the native AIX linker, so the handling for native AIX linkers
 works for binutils too.  I've therefore added a new variable that
 controls whether the GNU or native interface should be used.

 Tested using GCC.

 I'm not sure I understand correctly.  Did you run git Libtool's
 testsuite, after configuring it to use GCC and binutils?  In case not,
 please see the README file for how to run the test suites and report
 failures.

As you guessed, I hadn't done this, sorry.  All my testing at that
point had been using a cross GCC toolchain rather than a native one.
So it was tested using the GCC testsuite, but not the libtool testsuite.

I've now tested a native toolchain against both the gcc and libtool
testsuites.  The libtool testsuite did uncover other latent binutils
problems that still needed to be fixed, so thanks for that.  All the
fixes have now been applied to binutils CVS

 One thing that is missing from this patch is taking into account the
 non-whole-archive-like behavior of GNU ld on AIX.  I think it should
 cause some testsuite failures.  The setting of
 _LT_TAGVAR(whole_archive_flag_spec, TAG) may need adjustment (at least
 './libtool --config' output should differ in this respect from that with
 native ld).

Good catch, thanks.  Like you say, the libtool testsuite did show this.
(I deliberately ran it once without the fix as a smoke test.)

With this updated patch, the libtool results for GCC+binutils
are the same as those for the pre-installed GCC+native tools.

  * libltdl/m4/libtool.m4 (use_gnu_ld_interface): New variable
  to control whether the GNU ld or native ld interface is used.
  Set to no for GNU ld 2.19.50+ on AIX, otherwise mirror
  $with_gnu_ld.  Update the warning message that is printed
  when using GNU ld on AIX.

 Technical nit: use_gnu_ld_interface should probably be in the lt_*
 namespace.

Oops, done.

I've attached the updated patch.

Richard


* libltdl/m4/libtool.m4 (lt_use_gnu_ld_interface): New variable
to control whether the GNU ld or native ld interface is used.
Set to no for GNU ld 2.19.50+ on AIX, otherwise mirror
$with_gnu_ld.  Update the warning message that is printed
when using GNU ld on AIX.  Adjust the whole_archive_flag_spec
value for GNU ld on AIX.

Index: libltdl/m4/libtool.m4

Re: [PATCH] Fix GNU nm invocation for AIX

2009-04-24 Thread Richard Sandiford
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
 * Richard Sandiford wrote on Mon, Mar 16, 2009 at 10:53:23AM CET:
 AIX nm lists weak defined symbols like any other global symbol,
 whereas GNU nm lists them as W.  The export_symbols_cmds for
 GNU nm on AIX should therefore look for W in addition to the
 other codes.
 
 Tested using GCC.  Please install if OK.

 This patch is also ok if you state how you tested resp. show Libtool
 testsuite results.

Thanks.  Here are the results, after the updates described in my
last message.  I get the same results using the preinstalled GCC
with native tools.

Richard


gmake  check-recursive
gmake[1]: Entering directory `/export/richards/libtool'
rm -f tests/defs.tmp tests/defs; \
input=defs.m4sh; \
sed -e 's,@EGREP\@,/usr/bin/grep -E,g' -e 's,@FGREP\@,/usr/bin/grep -F,g' -e 
's,@GREP\@,/usr/bin/grep,g' -e 's,@LN_S\@,ln -s,g' -e 
's,@MACRO_VERSION\@,2.2.7a,g' -e 's,@PACKAGE\@,libtool,g' -e 
's,@PACKAGE_BUGREPORT\@,bug-libt...@gnu.org,g' -e 's,@PACKAGE_NAME\@,libtool,g' 
-e 's,@PACKAGE_STRING\@,libtool 2.2.7a,g' -e 's,@PACKAGE_TARNAME\@,libtool,g' 
-e 's,@PACKAGE_VERSION\@,2.2.7a,g' -e 's,@SED\@,/usr/bin/sed,g' -e 
's,@VERSION\@,2.2.7a,g' -e 's,@aclocaldir\@,/usr/local/share/aclocal,g' -e 
's,@datadir\@,/usr/local/share,g' -e 
's,@pkgdatadir\@,/usr/local/share/libtool,g' -e 
's,@host_triplet\@,powerpc-ibm-aix6.1.2.0,g' -e 's,@prefix\@,/usr/local,g' -e 
s,@configure_input\@,Generated from $input.,g ./tests/defs.in  
tests/defs.tmp; \
mv -f tests/defs.tmp tests/defs
gmake[2]: Entering directory `/export/richards/libtool'
gmake  check-TESTS check-local
gmake[3]: Entering directory `/export/richards/libtool'
PASS: tests/link.test
PASS: tests/link-2.test
PASS: tests/nomode.test
PASS: tests/objectlist.test
PASS: tests/quote.test
PASS: tests/sh.test
PASS: tests/suffix.test
PASS: tests/tagtrace.test
PASS: tests/cdemo-static.test
PASS: tests/cdemo-make.test
PASS: tests/cdemo-exec.test
PASS: tests/demo-static.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/demo-inst.test
PASS: tests/demo-unst.test
PASS: tests/depdemo-static.test
PASS: tests/depdemo-make.test
PASS: tests/depdemo-exec.test
PASS: tests/depdemo-inst.test
PASS: tests/depdemo-unst.test
PASS: tests/mdemo-static.test
PASS: tests/mdemo-make.test
PASS: tests/mdemo-exec.test
PASS: tests/mdemo-inst.test
PASS: tests/mdemo-unst.test
PASS: tests/cdemo-conf.test
PASS: tests/cdemo-make.test
PASS: tests/cdemo-exec.test
PASS: tests/demo-conf.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/demo-inst.test
PASS: tests/demo-unst.test
PASS: tests/demo-deplibs.test
PASS: tests/depdemo-conf.test
PASS: tests/depdemo-make.test
PASS: tests/depdemo-exec.test
PASS: tests/depdemo-inst.test
PASS: tests/depdemo-unst.test
PASS: tests/mdemo-conf.test
PASS: tests/mdemo-make.test
PASS: tests/mdemo-exec.test
PASS: tests/mdemo-inst.test
PASS: tests/mdemo-unst.test
PASS: tests/mdemo-dryrun.test
PASS: tests/mdemo2-conf.test
PASS: tests/mdemo2-make.test
PASS: tests/mdemo2-exec.test
PASS: tests/pdemo-conf.test
PASS: tests/pdemo-make.test
PASS: tests/pdemo-exec.test
PASS: tests/pdemo-inst.test
PASS: tests/demo-nofast.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/demo-inst.test
PASS: tests/demo-unst.test
PASS: tests/depdemo-nofast.test
PASS: tests/depdemo-make.test
PASS: tests/depdemo-exec.test
PASS: tests/depdemo-inst.test
PASS: tests/depdemo-unst.test
PASS: tests/demo-pic.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/demo-nopic.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/cdemo-shared.test
PASS: tests/cdemo-make.test
PASS: tests/cdemo-exec.test
PASS: tests/demo-shared.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/demo-inst.test
PASS: tests/demo-hardcode.test
PASS: tests/demo-relink.test
PASS: tests/demo-noinst-link.test
PASS: tests/demo-unst.test
PASS: tests/depdemo-shared.test
PASS: tests/depdemo-make.test
PASS: tests/depdemo-exec.test
PASS: tests/depdemo-inst.test
PASS: tests/depdemo-relink.test
PASS: tests/depdemo-unst.test
PASS: tests/mdemo-shared.test
PASS: tests/mdemo-make.test
PASS: tests/mdemo-exec.test
PASS: tests/mdemo-inst.test
PASS: tests/mdemo-unst.test
PASS: tests/cdemo-undef.test
PASS: tests/cdemo-make.test
PASS: tests/cdemo-exec.test
PASS: tests/tagdemo-static.test
PASS: tests/tagdemo-make.test
PASS: tests/tagdemo-exec.test
PASS: tests/tagdemo-conf.test
PASS: tests/tagdemo-make.test
PASS: tests/tagdemo-exec.test
PASS: tests/tagdemo-shared.test
PASS: tests/tagdemo-make.test
PASS: tests/tagdemo-exec.test
PASS: tests/tagdemo-undef.test
PASS: tests/tagdemo-make.test
PASS: tests/tagdemo-exec.test
PASS: tests/f77demo-static.test
PASS: tests/f77demo-make.test
PASS: tests/f77demo-exec.test
PASS: tests/f77demo-conf.test
PASS: tests/f77demo-make.test
PASS: tests/f77demo-exec.test
PASS: tests/f77demo-shared.test
PASS: tests/f77demo-make.test
PASS: tests/f77demo-exec.test
PASS: tests/fcdemo-static.test
PASS

Re: how to link with libtool?

2009-02-03 Thread Richard Purdie
On Tue, 2009-02-03 at 11:05 +0100, Matěj Týč wrote:
  Yes, it may be a good idea if somebody wrote this.
  It should probably depend on LT_OUTPUT.
 
  OTOH, the havelib module from gnulib already provides quite a bit of
  functionality in this area.
 
 OK, but what should I tell to the library users? Using gnulib is quite
 troublesome since
 it does not have proper documentation and usage of the library would become 
 too
 complicated for a casual programmer.
 And I don't like pkg-config since it breaks cross-compilation...

Just for reference, pkg-config should not break cross-compilation after
the addition of sysroot support to it. I keep meaning to look into
sysroot support for libtool too, I just haven't had the time yet :(.

Cheers,

Richard

-- 
Richard Purdie
Intel Open Source Technology Centre



___
http://lists.gnu.org/mailman/listinfo/libtool


Re: [PATCH] Add 64 bit directories to sys_lib_dlsearch_path_spec for Linux ELF

2009-01-28 Thread Richard Purdie

On Wed, 2009-01-28 at 12:01 -0800, Dan Nicholson wrote:
 If they follow the LSB, then they should be using lib64. However, you
 can configure the linker any number of ways. I tried to get a patch to
 glibc so this path could be determined, but it was rejected.
 
 http://sourceware.org/ml/libc-alpha/2008-12/msg00052.html
 
 I think this is the only reasonable way to proceed, but I suppose that
 an existence test would be safe, too:
 
 sys_lib_dlsearch_path_spec=/lib /usr/lib
 case `/usr/bin/file conftest.o` in
 *64-bit*)
 for dir in /lib64 /usr/lib64; do
 test -d $dir 
 sys_lib_dlsearch_path_spec=$sys_lib_dlsearch_path_spec $dir
 done
 ;;
 esac

Just as a datapoint, my standard ubuntu 64 bit desktop has /lib64 as a
symlink to /lib which has 64 bit libraries in it.

Cheers,

Richard

-- 
Richard Purdie
Intel Open Source Technology Centre



___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Compiling into chroot

2008-06-12 Thread Richard Purdie

On Thu, 2008-06-12 at 22:03 +0300, Alon Bar-Lev wrote:
 On 6/12/08, Roumen Petrov [EMAIL PROTECTED] wrote:
   It look like an enhancement request. libtool to obey as example
  FAKEROOT=/tmp/device-root and to look first in $FAKEROOT/path1
   , ... and $FAKEROOT/pathN and later in /path1,... and /pathN .
 
 This what I had in mind.
 It also should append the FAKEROOT to pathes read from .la files.

You mean prepend :)

This is the same issue as the sysroot one I've previously mentioned.
OpenEmbedded currently hacks the .la files in its staging area to
include the sysroot prefix but this means you can't use staging as a
chroot. I've not had time to look into doing anything about this feature
but I would love to see it!

Cheers,

Richard



___
http://lists.gnu.org/mailman/listinfo/libtool


Re: libtool 2.2.2, darwin and target prefixes

2008-05-02 Thread Richard Purdie
On Fri, 2008-05-02 at 01:03 -0500, Peter O'Gorman wrote:
 Peter O'Gorman wrote:
  Richard Purdie wrote:
  Hi,
 
  As previously mentioned, I've been stress testing libtool 2.2.2 with
  Poky a bit.
 
  I've found one issue when I tested the darwin builds, specifically that
  it tried to use otool and otool64 and not the versions with the host
  prefix which my setup has. I fixed this with the patch below which is
  fine for Poky since its always cross compiling but its a sign a better
  fix is probably needed in general.
  
  Thanks,
  I have pushed this, it also cleans up the sed sed echo ickyness.
 
 It is always better if quotes get closed. I had tested, honest!
 
 Pushed this.

I've updated Poky to use the proper fixes, thanks for looking at this!

Cheers,

Richard







Re: libtool 2.2.2, darwin and target prefixes

2008-05-02 Thread Richard Purdie
On Fri, 2008-05-02 at 01:03 -0500, Peter O'Gorman wrote:
 Peter O'Gorman wrote:
  Richard Purdie wrote:
  Hi,
 
  As previously mentioned, I've been stress testing libtool 2.2.2 with
  Poky a bit.
 
  I've found one issue when I tested the darwin builds, specifically that
  it tried to use otool and otool64 and not the versions with the host
  prefix which my setup has. I fixed this with the patch below which is
  fine for Poky since its always cross compiling but its a sign a better
  fix is probably needed in general.
  
  Thanks,
  I have pushed this, it also cleans up the sed sed echo ickyness.
 
 It is always better if quotes get closed. I had tested, honest!
 
 Pushed this.

I've updated Poky to use the proper fixes, thanks for looking at this!

Cheers,

Richard





___
http://lists.gnu.org/mailman/listinfo/libtool


libtool 2.2.2, darwin and target prefixes

2008-05-01 Thread Richard Purdie
Hi,

As previously mentioned, I've been stress testing libtool 2.2.2 with
Poky a bit.

I've found one issue when I tested the darwin builds, specifically that
it tried to use otool and otool64 and not the versions with the host
prefix which my setup has. I fixed this with the patch below which is
fine for Poky since its always cross compiling but its a sign a better
fix is probably needed in general.

Regards,

Richard

Index: libtool-2.2.2/libltdl/config/ltmain.m4sh
===
--- libtool-2.2.2.orig/libltdl/config/ltmain.m4sh   2008-05-01 
12:19:37.0 +0100
+++ libtool-2.2.2/libltdl/config/ltmain.m4sh2008-05-01 12:29:05.0 
+0100
@@ -4965,10 +4965,10 @@
done
if test -f $absdir/$objdir/$depdepl ; then
  depdepl=$absdir/$objdir/$depdepl
- darwin_install_name=`otool -L $depdepl | $SED -n -e 
'3q;2,2p' | $SED -e 's/(.*//'`
+ darwin_install_name=`$host-otool -L $depdepl | $SED -n -e 
'3q;2,2p' | $SED -e 's/(.*//'`
  darwin_install_name=`$ECHO $darwin_install_name`
   if test -z $darwin_install_name; then
-  darwin_install_name=`otool64 -L $depdepl | $SED -n 
-e '3q;2,2p' | $SED -e 's/(.*//'`
+  darwin_install_name=`$host-otool64 -L $depdepl | 
$SED -n -e '3q;2,2p' | $SED -e 's/(.*//'`
   darwin_install_name=`$ECHO $darwin_install_name`
   fi
  compiler_flags=$compiler_flags ${wl}-dylib_file 
${wl}${darwin_install_name}:${depdepl}



___
http://lists.gnu.org/mailman/listinfo/libtool


Re: libtool 2.2.2, ccache and -all-static

2008-04-22 Thread Richard Purdie
Hi Ralf,

On Tue, 2008-04-22 at 21:43 +0200, Ralf Wildenhues wrote:
 Thanks for the bug report, and especially for providing an example to
 reproduce it!
 
  libtool: link: ccache -static gcc -O20 -ffast-math -D_REENTRANT 
  -fsigned-char -DUSE_MEMORY_H -o decoder_example decoder_example.o  
  ../lib/.libs/libvorbis.a -lm /usr/lib/libogg.a
 
 Confirmed.  Fixed as below, committed, put you in THANKS.

I've confirmed the fix, added it to Poky and dropped the hacks I had,
thanks!

Cheers,

Richard





libtool 2.2.2, ccache and -all-static

2008-04-22 Thread Richard Purdie
Hi,

I've noticed another problem with two packages in poky, prelink and
libvorbis. Both packages have areas where LDFLAGS=-all-static is used.

The problem comes about since Poky sets CC to ccache gcc, then libtool
puts the -static flag between ccache and gcc.

To reproduce:

wget http://www.vorbis.com/files/1.0.1/unix/libvorbis-1.0.1.tar.gz
tar -xvzf /usr/oe/sources/libvorbis-1.0.1.tar.gz
cd libvorbis-1.0.1
autoreconf -i
CC=ccache gcc ./configure
make

which results in:

make[1]: Entering directory `/usr/src/libvorbis-1.0.1/examples'
ccache gcc -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ 
-DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\libvorbis\ 
-DVERSION=\1.0.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 
-DLT_OBJDIR=\.libs/\ -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -I. -I../include 
-O20 -ffast-math -D_REENTRANT -fsigned-char  -DUSE_MEMORY_H -MT 
decoder_example.o -MD -MP -MF .deps/decoder_example.Tpo -c -o decoder_example.o 
decoder_example.c
mv -f .deps/decoder_example.Tpo .deps/decoder_example.Po
/bin/sh ../libtool --tag=CC   --mode=link ccache gcc  -O20 -ffast-math 
-D_REENTRANT -fsigned-char  -DUSE_MEMORY_H  -all-static -o decoder_example 
decoder_example.o ../lib/libvorbis.la -lm  -logg
libtool: link: ccache -static gcc -O20 -ffast-math -D_REENTRANT -fsigned-char 
-DUSE_MEMORY_H -o decoder_example decoder_example.o  ../lib/.libs/libvorbis.a 
-lm /usr/lib/libogg.a

which then fails with the ccache help message since it doesn't support a
-static option. Is it possible to fix this so the flag is properly
handled?

Cheers,

Richard



___
http://lists.gnu.org/mailman/listinfo/libtool


Problems with libtool 2.2.2 and /bin/sh pointing to dash

2008-04-21 Thread Richard Purdie
Hi,

I've had reports of Poky breaking with libtool 2.2.2 and have isolated
this to people using dash as their /bin/sh provider (Poky runs the
configure script with /bin/sh). When used in this combination, the
global_symbol_pipe expression becomes corrupted in the generated libtool
file amongst other things and I've included a diff of the corruption
below. I noticed this with gtk+ 2.12.7. 

gtk+ also has the issues that it tries to run libtool before its been
generated and I've had to patch this to run a previously generated
version of libtool poky has around to solve cases like this. I'm not
sure if there is a neater way to address that problem?

Regards,

Richard

--- libtool-bash2008-04-21 17:57:40.0 +0100
+++ libtool-dash2008-04-21 23:36:38.0 +0100
@@ -1,4 +1,4 @@
-#! /bin/sh
+#! /bin/bash
 
 # arm-poky-linux-gnueabi-libtool - Provide generalized library-building 
support services.
 # Generated automatically by config.status (gtk+) 2.12.7
@@ -107,10 +107,10 @@
 lt_unset=unset
 
 # turn spaces into newlines.
-SP2NL=tr \\040 \\012
+SP2NL=tr \040 \012
 
 # turn newlines into spaces.
-NL2SP=tr \\015\\012 \\040\\040
+NL2SP=tr \015\012 \040\040
 
 # How to create reloadable object files.
 reload_flag= -r
@@ -141,22 +141,22 @@
 LTCFLAGS=-fexpensive-optimizations -fomit-frame-pointer -frename-registers 
-O2 -Wall
 
 # Take the output of nm and produce a listing of raw symbols and C names.
-global_symbol_pipe=sed -n -e 's/^.*[   ]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[  
 ][  ]*\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2 \\2/p'
+global_symbol_pipe=sed -n -e 's/^.*[   ]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[  
 ][  ]*\\([_A-Za-z][_A-Za-z0-9]*\\)\$/  /p'
 
 # Transform the output of nm in a proper C declaration.
-global_symbol_to_cdecl=sed -n -e 's/^T .* \\(.*\\)\$/extern int \\1();/p' -e 
's/^[ABCDGIRSTW]* .* \\(.*\\)\$/extern char \\1;/p'
+global_symbol_to_cdecl=sed -n -e 's/^T .* \\(.*\\)\$/extern int ();/p' -e 
's/^[ABCDGIRSTW]* .* \\(.*\\)\$/extern char ;/p'
 
 # Transform the output of nm in a C name address pair.
-global_symbol_to_c_name_address=sed -n -e 's/^: \\([^ ]*\\) \$/  
{\1\\\, (void *) 0},/p' -e 's/^[ABCDGIRSTW]* \\([^ ]*\\) \\([^ ]*\\)\$/  
{\\\2\, (void *) 2},/p'
+global_symbol_to_c_name_address=sed -n -e 's/^: \\([^ ]*\\) \$/  {\\\\\\, 
(void *) 0},/p' -e 's/^[ABCDGIRSTW]* \\([^ ]*\\) \\([^ ]*\\)\$/  {\\, (void 
*) \\},/p'
 
 # Transform the output of nm in a C name address pair when lib prefix is 
needed.
-global_symbol_to_c_name_address_lib_prefix=sed -n -e 's/^: \\([^ ]*\\) \$/  
{\1\\\, (void *) 0},/p' -e 's/^[ABCDGIRSTW]* \\([^ ]*\\) \\(lib[^ 
]*\\)\$/  {\\\2\, (void *) 2},/p' -e 's/^[ABCDGIRSTW]* \\([^ ]*\\) \\([^ 
]*\\)\$/  {\lib\\2\, (void *) 2},/p'
+global_symbol_to_c_name_address_lib_prefix=sed -n -e 's/^: \\([^ ]*\\) \$/  
{\\\\\\, (void *) 0},/p' -e 's/^[ABCDGIRSTW]* \\([^ ]*\\) \\(lib[^ ]*\\)\$/  
{\\, (void *) \\},/p' -e 's/^[ABCDGIRSTW]* \\([^ ]*\\) \\([^ ]*\\)\$/  
{\lib\, (void *) \\},/p'
 
 # The name of the directory that contains temporary libtool files.
 objdir=.libs
 
 # Shell to use when invoking shell scripts.
-SHELL=/bin/sh
+SHELL=/bin/bash
 
 # An echo program that does not interpret backslashes.
 ECHO=echo
@@ -301,7 +301,7 @@
 # Commands used to build a shared archive.
 archive_cmds=\$CC -shared \$libobjs \$deplibs \$compiler_flags \${wl}-soname 
\$wl\$soname -o \$lib
 archive_expsym_cmds=echo \\\{ global:\\\  \$output_objdir/\$libname.ver~
-   cat \$export_symbols | sed -e \\\s/(.*)/1;/\\\  
\$output_objdir/\$libname.ver~
+   cat \$export_symbols | sed -e \\\s/(.*)/;/\\\  
\$output_objdir/\$libname.ver~
echo \\\local: *; };\\\  \$output_objdir/\$libname.ver~
\$CC -shared \$libobjs \$deplibs \$compiler_flags \${wl}-soname 
\$wl\$soname \${wl}-version-script \${wl}\$output_objdir/\$libname.ver -o \$lib
 



___
http://lists.gnu.org/mailman/listinfo/libtool


Re: libtool.m4 not always copied

2008-04-16 Thread Richard Purdie
Hi,

On Wed, 2008-04-16 at 19:03 +0200, Vincent Torri wrote:
 I'm using libtool 2.2.3a (cvs, actually) and i'm trying to find out why 
 some lib are not configured correctly, while other are.
 
 My problem is that ECHO and OBJDUMP are not defined when I'm configuring 
 libpng 1.2.26, while it's perfectly defined with another lib. I'm doing 
 cross-compiling for the cegcc compiler (i've improved the patch i've sent 
 to the libtool patch ML, but i want to solve all the problems i encounter 
 before sending it again).
 
 I've grep'ed OBJDUMP and i've remarked that with libpng, it's never 
 defined, and in addition libtool.m4 and other m4 files that lib should 
 (must ?) copy are not in the libpng directory. I don't know if it's 
 related, but i prefer asking anyway :)
 
 I have the same problem with ECHO, which is not defined too.
 
 With the other lib, there is no problem at all. The m4 files are correctly 
 copied and used.
 
 So I would like to know why libtoolize does not copy those files with the 
 libpng library. And if someone knows why OBJDUMP is not defined, i would 
 be glad to know :)

I'm in the process of upgrading Poky to use libtool 2.2.2 and noticed
the echo problem. libtool.m4 was correctly added to aclocal.m4 though
and I didn't see the OBJDUMP problem.

To 'fix' the echo issue I added:

http://svn.o-hand.com/view/poky/trunk/meta/packages/libpng/libpng-1.2.16/makefile_fix.patch?rev=4267view=markup

although I suspect echo = @ECHO@ might be better. I think libpng has
relied on old libtool behaviour which happened to export that and no
longer does so its a libpng bug but I'm open to more informed comments!

Cheers,

Richard




___
http://lists.gnu.org/mailman/listinfo/libtool


Re: libtool.m4 not always copied

2008-04-16 Thread Richard Purdie
On Wed, 2008-04-16 at 23:56 +0200, Ralf Wildenhues wrote:
 * Richard Purdie wrote on Wed, Apr 16, 2008 at 07:10:54PM CEST:
  To 'fix' the echo issue I added:
  
  http://svn.o-hand.com/view/poky/trunk/meta/packages/libpng/libpng-1.2.16/makefile_fix.patch?rev=4267view=markup
  
  although I suspect echo = @ECHO@ might be better. I think libpng has
  relied on old libtool behaviour which happened to export that and no
  longer does so its a libpng bug but I'm open to more informed comments!
 
 Sorry, but your patch just hides the real bug that you're using macro
 files from Libtool 1.5.x.  You will see other, more obscure bugs (but
 then again, with their nature of being obscure, you may not see them,
 but curse a lot about how broken Libtool is).
 
 Please drop the patch and get updated macros into your tree.

I am not using 1.5 macros. libtool 2.2.2 is being used, as I can see if
I grep aclocal.m4 or ltmain.sh for the libtool version.

Let me try again to explain the problem. Makefile.am contains:

$(ECHO) [EMAIL PROTECTED]@@[EMAIL PROTECTED] '{global:'  [EMAIL 
PROTECTED]
$(SED) s/$$/\;/ libpng.sym  [EMAIL PROTECTED]
$(ECHO) 'local: *; };'  [EMAIL PROTECTED]

automake expands ECHO_C, ECHO_N, ECHO_T and lt_ECHO but not ECHO
anymore. libtool 1.5 macros happened to let ECHO be expanded but in
2.2.2 this is lt_ECHO.

Since nothing expands ECHO anymore this breaks with libtool 2.2.2.

I think that libpng is in the wrong here though and it therefore needs
to add something to the Makefile.am to cause ECHO to expand.

Cheers,

Richard





___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

2008-04-13 Thread Richard Purdie
Josh Triplett josh at freedesktop.org writes:
 Thus, I wrote Dolt, a drop-in replacement for libtool's compilation
 mode.  Dolt runs any necessary system-specific or
 configuration-specific logic as part of configure, writes out a simple
 shell script doltcompile[1], and substitutes it for libtool in the
 automake variables LTCOMPILE and LTCXXCOMPILE.  If you use automake,
 autoconf, and libtool, then using Dolt just requires two steps:
 
 1) add DOLT after the call to LT_INIT, AC_PATH_LIBTOOL, or
AM_PATH_LIBTOOL in your configure.ac or configure.in script, and
 2) append dolt.m4 to your project's acinclude.m4.
 
 For any system Dolt does not support, it will transparently fall back
 to libtool.

I work with Poky (pokylinux.org) and OpenEmbedded (openembedded.org) which are
cross compiling build systems and speed improvements like this are extremely
useful to us. Those systems also provide an interesting testing ground
where we can expose changes like this to a wide variety of source code.

I found this last part doesn't hold true, dolt does not fall back to
libtool transparently, the reason being the AC_SUBST causes LTCOMPILE to
become , even if that section of the if block isn't called. I couldn't
find a nice way to fix this since AC_SUBST operates at reautoconf time,
not at configure and you only know if the system is compatible at
configure time.

Poky/OE use an old libtool (1.5.10) since we have various hacks we had
to make to get libtool to support cross compiling sanely[1] and
everytime we've tried to upgrade, something goes wrong and we've never
had time to debug the newer versions.

[1] Are there any plans to support sysroots with libtool?

In the interests of experimentation I hacked dolt into our libtool
recipe, inserting it into libtool.m4 in AC_PROG_LIBTOOL so I didn't have
to change any apps. I enabled it for arm linux targets and removed the
broken fallback code. The test build I used as a benchmark builds a
cross compiling toolchain and then from that a complete PDA style system
including X and some GTK+ apps with all the parts in between, many of
which use libtool.

Before the dolt change this image took 108 minutes, afterwards it took
96 minutes so an 11% reduction in time which is certainly beneficial!

Cheers,

Richard



___
http://lists.gnu.org/mailman/listinfo/libtool


Re: sysroot support in libtool

2008-04-13 Thread Richard Purdie
Hi,

On Sun, 2008-04-13 at 08:21 -0400, Gary V. Vaughan wrote:
 On 13 Apr 2008, at 07:55, Richard Purdie wrote:
  [1] Are there any plans to support sysroots with libtool?
 
 No one is sending us bug reports or patches... so we don't even know
 there is a problem!

Ok, there are some fairly long running issues with OpenEmbedded and
libtool. I appreciate there has not been feedback to upstream about the
problems and this is entirely our fault. There are various reasons for
this:

* the person who integrated libtool into OE has moved onto other things
  and the knowledge for a lot of the magic was lost
* we're stuck on an old version of libtool (1.5.10) which we know you 
  won't be interested in bugs against
* this old version works and nobody has found the time for the 
  learning curve and debugging involved in upgrading

More recently a lot of things have changed for the better in OE and
we're striving for a clean logical build structure rather than hacks,
I've been one of the people trying to achieve this. One way we've done
this is embracing the sysroot options in gcc/binutils and getting
sysroot support into pkg-config.

So this leaves us with the problem of libtool. Why a problem?

Lets give an example of compiling some library which uses libtool and
autotools:

* We configure it with libdir=/usr/lib which is where the library will
be on the target system ultimately.
* Compile it using a gcc cross compiler and binutils which have been
configured with /somewhere/sysroot as the sysroot. This means they don't
look in /usr/lib and /usr/include, they look
in /somewhere/sysroot/usr/lib and /somewhere/sysroot/usr/include.
* We make install DESTDIR=/someplace and then build packages out
of /someplace
* We make install DESTDIR=/somewhere/sysroot which adds the library to
our sysroot environment so something using this lib can compile against
it.

The problem is this last step which installs .la files into our sysroot
which don't work. The issues we can have:

* The .la files say installed=yes but they're in the sysroot, not in
libdir.
* dependency_libs= can contain an expanded version of libdir. This is
wrong and we have to prepend the sysroot to this.
* libdir itself can be added to the search path for libraries which
finds things from /usr/lib on the host system - really bad when cross
compiling

To workaround these issues we sed the sysroot .la files to:

* change installed=yes to installed=no, it changes some of the logic
within libtool and breaks some assumptions about the files being in
libdir which helps.
* prepend sysroot to the appropriate parts of dependency_libs

and patch libtool to:

* remove the parts which add libdir into the search path
* cope with the installed=no logic and search both the sysroot and the
app being compiled

The above is the situation with 1.5.10. I've just tried a build with a
clean 2.2.2 and it broke with at least one of the problems mentioned
above, I don't know if all the above issues are still present but I
suspect they are meaning I need to forward port our hacks.

Whats the dream solution? We can set an environmental variable say
LIBTOOL_SYSROOT=/somewhere/sysroot and libtool would take this into
account exactly where needed and just work. The .la files in our
sysroot would match those we install onto the target system.

Its possible things have changed and libtool has some mechanism to cope
with setups like this and if so please let me know what they are! If not
does the above illustrate the problem and is this something you'd be
prepared to help fix?

In the meantime I will try and get Poky/OE using a much more recent
libtool, patched enough so builds continue to work as described above.
Once we get a modern version working it will be much easier to test
patches and improvements in libtool and from what I've read, we should
see some performance improvements which would be most welcome. We don't
have patches to add sysroot support, just the sed hacks I've mentioned
but if you'd be interested in proper sysroot support that is something
we'd be interested in collaborating on.

Cheers,

Richard




___
http://lists.gnu.org/mailman/listinfo/libtool


Re: sysroot support in libtool

2008-04-13 Thread Richard Purdie
Hi Ralf,

On Sun, 2008-04-13 at 17:09 +0200, Ralf Wildenhues wrote:
 * Richard Purdie wrote on Sun, Apr 13, 2008 at 04:59:26PM CEST:
  
  * the person who integrated libtool into OE has moved onto other things
and the knowledge for a lot of the magic was lost
  * we're stuck on an old version of libtool (1.5.10) which we know you 
won't be interested in bugs against
 
  * this old version works [...]
 
 No it doesn't.  If it did, you wouldn't be adopting dolt.
 OK, you put works in quotes, so I guess that's what you meant.

works means that with our patched 1.5.10 libtool OE/Poky can generate
working cross compiled binaries and images. Its in quotes since I don't
like the way we do it but having working builds with some ugliness
behind the scenes is better than ones that don't work!

dolt comes in purely as a speedup, it doesn't make the .la file and
sysroot situation better or worse.

  In the meantime I will try and get Poky/OE using a much more recent
  libtool, patched enough so builds continue to work as described above.
  Once we get a modern version working it will be much easier to test
  patches and improvements in libtool and from what I've read, we should
  see some performance improvements which would be most welcome. We don't
  have patches to add sysroot support, just the sed hacks I've mentioned
  but if you'd be interested in proper sysroot support that is something
  we'd be interested in collaborating on.
 
 Even posting the sed hacks or the diffs against 1.5.10 that you were
 using (both to libtool-patches, please) are better than nothing.

I'll post here first, since I don't class any of these are ready to
apply and really need discussion. If you still feel libtool-patches is
more appropriate for that tell me and I'll switch lists though.

The patches we're using are publicly available as:
http://svn.o-hand.com/view/poky/trunk/meta/packages/libtool/libtool-1.5.10/

I've run through each with a quick description of what it does

3figures.patch - a better version was merged, not needed with 2.2.2

add_dolt.patch - hacks dolt into libtool.m4 instead of patching every
configure.ac. Inappropriate for upstream, mentioned for reference only.

autotools.patch - Make the old libtool work with more modern autotools.
Not needed with 2.2.2.

install-path-check.patch - OE used to have a staging layout which didn't
match the target system. Since we use sysroot this shouldn't be needed
anymore.

libdir-la.patch - See comments in the patch. Doesn't add libdir to the
search path, don't complain about 'moved' files, don't replace
uninstalled with installed libraries

libdir-la2.patch - Improves on the above to stop libdir leaking into
search paths and checking more locations in the installed=no case.

nmedit_fix.patch - Call host-triplet-nmedit, not just nmedit

nousrlib.patch - Stop libdir leaking into linker flags

prefix.patch - Rename libtool to be prefixed by the host triplet which
makes it much more obvious when the wrong libtool is being used and is
in line with autotools wanting cross tool names prefixed with the
triplet.

sedvar.patch - Fixes some issue we saw when $SED wasn't set

tag.patch - The tag errors were breaking things for no good reason so we
turned the error into a warning

uclibc.patch - Tweaks to libtool.m4 to support uclibc


I don't have the full background on all of these and have only checked
whether some are needed against 2.2.2, I'll aim to do the rest soon and
try to get 2.2.2 working. The core patches are the libdir-la.patch,
lidir-la2.patch and prefix.patch, all of which I know are still needed.

The sed magic I mentioned is in
http://svn.o-hand.com/view/poky/trunk/meta/classes/base.bbclass?rev=4064view=markup

specifically:

sed -e 's/^installed=yes$/installed=no/' \
 -e 
'/^dependency_libs=/s,${WORKDIR}[[:alnum:]/\._+-]*/\([[:alnum:]\._+-]*\),${STAGING_LIBDIR}/\1,g'
 \
 -e /^dependency_libs=/s,\([[:space:]']+\)${libdir},\1${STAGING_LIBDIR},g 
\
 $dotlai $destpath/$libname.la

which changes installed=yes to installed=no and cleans up
dependency_libs so it only refers to 'staging' (the sysroot), not the
work directories (which are temporary in nature) or libdir (which are
binaries from the wrong architecture).

 Proper sysroot support in Libtool would be very welcome, but
 unfortunately it won't be easy.  Of course there are more constraints:
 it should work right in most practical cases, not just the ones your
 package cares about.  Since it cannot be made to work on some systems
 due to linker and binary file format limitations, it should degrade
 gracefully on those systems.
 
 I've tried it a couple of years ago, but gave up since I figured it
 would take me all remaining weekends of the year to do.

I agree it won't be easy. If I knew it stood a chance of being accepted
into libtool and/or that others were prepared to help with it, that
might encourage me to start writing some patches though. It has the
advantage of being opt in since if sysroot

Re: sysroot support in libtool

2008-04-13 Thread Richard Purdie
On Sun, 2008-04-13 at 22:26 +0200, Ralf Wildenhues wrote:
 * Richard Purdie wrote on Sun, Apr 13, 2008 at 08:53:10PM CEST:
  
  The patches we're using are publicly available as:
  http://svn.o-hand.com/view/poky/trunk/meta/packages/libtool/libtool-1.5.10/
 
 Let's take a look at the simple ones:
 
  nmedit_fix.patch - Call host-triplet-nmedit, not just nmedit
 
 This patch shouldn't be needed any more with 2.2.2.

Agreed, the nmedit code looks much neater now!

  sedvar.patch - Fixes some issue we saw when $SED wasn't set
 
 Shouldn't be needed any more either.

Agreed.

  tag.patch - The tag errors were breaking things for no good reason so we
  turned the error into a warning
 
 Well, don't come crying for bad performance to us if you do things like
 this.  Letting libtool infer the tag is rather expensive, at least
 relatively, for 2.2.2 on modern systems where there are few other forks
 needed.

Going totally from memory, I think this exists since we have CC set to
things like:

CC=gcc -march=armv5te -mtune=xscale

and then this might change to

CC=gcc -march=armv5te -mtune=arm926ejs

which is 100% binary compatible, just optimised differently. libtool
upon seeing CC change gets upset. Sadly I can't remember how libtool
notices this change, it much be through some kind of state information
libtool saves into our staging area.

Thanks for the pointer on this though, I will look into it and find some
way to avoid it. 

  uclibc.patch - Tweaks to libtool.m4 to support uclibc
 
 If this happens to be needed for 2.2.2 as well, I'd like this one
 submitted to libtool-patches, ideally including a ChangeLog entry
 and testsuite results for this system, thanks.

Ok, I'll keep this in mind when updating and submit it if its still
needed.

Just for reference,
http://svn.o-hand.com/view/poky/trunk/meta/packages/libtool/libtool-2.2.2/
are the needed patches updated for 2.2.2, albeit rather untested at the
moment.

Cheers,

Richard




___
http://lists.gnu.org/mailman/listinfo/libtool


Re: make -s

2008-01-14 Thread Richard Hacker
On Sunday 13 January 2008 17:46, Ralf Wildenhues wrote:
 * Richard Hacker wrote on Fri, Jan 11, 2008 at 01:21:50PM CET:

  However, libtool is responsible for parsing *make's *FLAGS

 Now, this contradicts your statement (*) above, no?
Oppps, my mistake. Sorry for confusing everyone :-(
No, as you correctly read and interpreted, I meant to say that libtool should 
NOT parse their caller's *FLAGS. The caller (i.e. automake in this case) 
should be responsible for calling its subcommands with their respective 
silent flags set as far as they exist. Think of the case when a new supermake 
enters the scene and the authors of all the various tools that it calls have 
to implement yet another SUPERMAKEFLAGS. 
This concept does not scale well.

 If `make -s' were to influence libtool verbosity, there are several
 choices to implement this:
 - inside the libtool script, parse MAKEFLAGS
poor IMHO
 - automake hackery that puts necessary code in Makefile.in so that upon
   `make -s', libtool is called with --silent
better

 The second choice leaves users of make-without-automake in the cold, ...
It is the duty of the various *make developers to implement a silent mode...
 but 
 my assumption is that none of you care about it (of course they could
 always copy that implementation).  It also carries the burden of larger
 Makefiles, likely even more verbose output when `make' is issued without
 `-s'.
Why should the output of a make without '-s' be larger? I do not see this 
necessity.

 The problem of implementing the required logic in a Makefile is that,
 while it is quite cheap to do with GNU make, I only see ugly solutions
 that work with portable make.  They either
 - require the choice of silency to be made at configure time already,
Poor IMHO. make's -s switch is dynamic in nature and this spirit should be 
kept with a silent or not silent implementation is planned
 
 If someone sees a way to avoid these, I'd love to hear about it.
There should be some if make_is_silent; AM_LIBTOOLFLAGS += --silent; endif 
construct inside Makefile.in. However, I have not seen any if...endif 
constructs in Makefile.in as a starting point for writing portable make 
commands.

 FWIW, here's a patch that goes the ugly design way of implementing
 this in libtool, which I think is portable.
At least it works inside the autoconf, automake, libtool toolset. This is a 
very common setup.

But thanks for the patch. I'll be using it shortly. It is more professional 
than my one ;-)

Regards
- Richard


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: make -s

2008-01-11 Thread Richard Hacker
On Thursday 10 January 2008 21:30, Ralf Wildenhues wrote:
   If you want all tools silenced which are called by make, then I suggest
   to simply use
 make /dev/null || make
 
  well, we're after the automatic output going away, not intended output.

 So what's intended output?  
I think that the output should be similar to make -s. This is also not 
completely quiet, compiler warnings and the like are shown. It just means 
that the make commands should not be shown, whereas the output of the 
commands are very well. This reduces much of the 'make noise' and reduces the 
output to compiler warnings and errors. Quite honestly, I recently oversaw a 
compiler warning due to noise because I was on the command line and not in an 
editor.

 Should libtool parse their $TOOLFLAGS too?
Good point. No not really. Why should the tools parse their caller's flags? 
Quite frankly, make should be the one that calls the various tools with their 
respective --silent flag set, not the other way 'round, right?

 If all you want is libtool to go silent globally in your package then
 what about just
   AC_SUBST([AM_LIBTOOLFLAGS], [--silent])
This is not the intention of the root of this discussion. Just as well as 
make /dev/null 21
is also not the point. 

If libtool complains, it should show it, whether it be stdout or stderr, it 
should all be shown. However, the ugly  ;)
'g++ -DHAVE_CONFIG_H -I. -I. -I. -Wall -g -O2 .' 
that libtool calls is not really essential to the programmer when (s)he calls 
make -s. 

True, my editor should pick up these compiler warnings, but funnily enough, my 
vim allways ends up with a blank buffer after doing :make but not 
with ':make -s' when I use my patch to silence libtool.

So, here is my modest opinion. If I as a programmer call
*) 'make' on its own, it should show its commands as well as their output
*) 'make -s', it should not show the commands it calls, only the output of 
these.
However, libtool is responsible for parsing *make's *FLAGS

Cheers
- Richard


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: make -s

2008-01-10 Thread Richard Hacker
On Thursday 10 January 2008 08:29, Ralf Wildenhues wrote:
 For whatever output is left done by libtool I expect that whoever want's
 it silenced hard enough will have enough motivation to send a patch to
 libtool-patches@gnu.org.
That shouldn't bee too difficult.

As a hint, make adds 's' to the environment variable MAKEFLAGS:
MAKEFLAGS=s

MFLAGS=-s also exists, but its use seems to be superceded by MAKEFLAGS

When I change ltmain.sh using the following patch, it seems to work. I am 
using
# libtool --version
ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)

I hope this patch is portable I am certainly no expert in portability!

 patch start 
--- old/ltmain.sh   2006-11-25 12:34:55.0 +0100
+++ /usr/share/libtool/ltmain.sh2008-01-10 13:28:59.0 +0100
@@ -384,6 +384,15 @@
 done
 func_extract_archives_result=$my_oldobjs
 }
+
+func_is_make_silent ()
+{
+case $1 in
+*s*) true;;
+*) false;;
+esac
+}
+
 # End of Shell function definitions
 #

@@ -392,6 +401,12 @@

 disable_libs=no

+if func_is_make_silent $MAKEFLAGS
+then
+   show=:
+   preserve_args=$preserve_args $arg
+fi
+
 # Parse our command line options once, thoroughly.
 while test $# -gt 0
 do
 patch end 

- Richard




Re: make -s

2008-01-10 Thread Richard Hacker
On Thursday 10 January 2008 08:29, Ralf Wildenhues wrote:
 For whatever output is left done by libtool I expect that whoever want's
 it silenced hard enough will have enough motivation to send a patch to
 [EMAIL PROTECTED].
That shouldn't bee too difficult.

As a hint, make adds 's' to the environment variable MAKEFLAGS:
MAKEFLAGS=s

MFLAGS=-s also exists, but its use seems to be superceded by MAKEFLAGS

When I change ltmain.sh using the following patch, it seems to work. I am 
using
# libtool --version
ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)

I hope this patch is portable I am certainly no expert in portability!

 patch start 
--- old/ltmain.sh   2006-11-25 12:34:55.0 +0100
+++ /usr/share/libtool/ltmain.sh2008-01-10 13:28:59.0 +0100
@@ -384,6 +384,15 @@
 done
 func_extract_archives_result=$my_oldobjs
 }
+
+func_is_make_silent ()
+{
+case $1 in
+*s*) true;;
+*) false;;
+esac
+}
+
 # End of Shell function definitions
 #

@@ -392,6 +401,12 @@

 disable_libs=no

+if func_is_make_silent $MAKEFLAGS
+then
+   show=:
+   preserve_args=$preserve_args $arg
+fi
+
 # Parse our command line options once, thoroughly.
 while test $# -gt 0
 do
 patch end 

- Richard


___
http://lists.gnu.org/mailman/listinfo/libtool


Problem with libtool

2008-01-10 Thread Richard Graham
I am trying to build Open MPI on the Cray's (Compute Node Linux), and ran
into the following problem.  In our configure script we get the wl parameter
set to -Wl,

But when the following part of the build is run:

/bin/sh ../../../libtool --tag=CC   --mode=link cc  -O2
-I/opt/xt-pe/default/include/   -L/opt/xt-mpt/default/lib/snos64/  -o
orteboot orteboot.o ../../../orte/libopen-rte.la  -lnsl -lutil -lpct
-lalpslli -lalpsutil


It results in:
cc -O2 -I/opt/xt-pe/default/include/ -o orteboot orteboot.o
-L/opt/xt-mpt/default/lib/snos64/ ../../../orte/.libs/libopen-rte.a
-L/opt/torque/2.2.0-snap.200711011704/lib
/opt/torque/2.2.0-snap.200711011704/lib/libtorque.so
/ccs/home/rlgraham/orte_cnl/opal/.libs/libopen-pal.a -lnsl -lutil -lpct
-lalpslli -lalpsutil --rpath /opt/torque/2.2.0-snap.200711011704/lib --rpath
/opt/torque/2.2.0-snap.200711011704/lib

Loosing the -Wl, value.  Insteat of -Wl,--rpath I get --rpath, which the pgi
compiler does not recognize.  Are there any hints on how to trouble shoot
this ?

I manually ran:
/bin/sh ../../../libtool --tag=CC   --mode=link cc  -O2
-I/opt/xt-pe/default/include/   -L/opt/xt-mpt/default/lib/snos64/  -o
orteboot orteboot.o ../../../orte/libopen-rte.la  -lnsl -lutil -lpct
-lalpslli -lalpsutil

And here is some (seemingly) relevant output:
+ reload_cmds=$LD$reload_flag -o $output$reload_objs
+ wl=
+ objext=o
+ libext=a
+ shrext_cmds=.so

I am sure this is incomplete information, but am not sure what else to
provide to help diagnose this.

Thanks,
Rich



___
Bug-libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-libtool


  1   2   >