Patchwork build: add -Wl,-rpath=path to $gmplibs (issue 7124057)

login
register
mail settings
Submitter minux.ma@gmail.com
Date Jan. 17, 2013, 7:11 p.m.
Message ID <047d7b6d7cc0187e9504d380c271@google.com>
Download mbox | patch
Permalink /patch/213352/
State New
Headers show

Comments

minux.ma@gmail.com - Jan. 17, 2013, 7:11 p.m.
Reviewers: bonzini_gnu.org, dj_redhat.com, neroden_gcc.gnu.org,  
aoliva_redhat.com, ralf.wildenhues_gmx.de,

Message:
some systems (notably NetBSD), doesn't place the path where libgmp,
libmpfr, libmpc resides into /etc/ld.so.conf, and instead rely on
the binary providing correct -rpath; this patch adds the required
-Wl,-rpath=path to $gmplibs so that when bootstrapping gcc,
the various language frontends (cc1, etc) could run in that case.

I assume all the linkers that gcc bootstraps with have support for
the -rpath flag.

Description:
2013-01-18  Shenghou Ma  <minux.ma@gmail.com>

	* configure.ac: add -Wl,-rpath=path to $gmplibs
	* configure: Re-generate.


Please review this at https://codereview.appspot.com/7124057/

Affected files:
   M     configure
   M     configure.ac


    gmplibs='-L$$r/$(HOST_SUBDIR)/gmp/'"$lt_cv_objdir $gmplibs"
Jakub Jelinek - Jan. 17, 2013, 7:16 p.m.
On Thu, Jan 17, 2013 at 07:11:12PM +0000, minux.ma@gmail.com wrote:
> Reviewers: bonzini_gnu.org, dj_redhat.com, neroden_gcc.gnu.org,
> aoliva_redhat.com, ralf.wildenhues_gmx.de,
> 
> Message:
> some systems (notably NetBSD), doesn't place the path where libgmp,
> libmpfr, libmpc resides into /etc/ld.so.conf, and instead rely on
> the binary providing correct -rpath; this patch adds the required
> -Wl,-rpath=path to $gmplibs so that when bootstrapping gcc,
> the various language frontends (cc1, etc) could run in that case.
> 
> I assume all the linkers that gcc bootstraps with have support for
> the -rpath flag.
> 
> Description:
> 2013-01-18  Shenghou Ma  <minux.ma@gmail.com>
> 
> 	* configure.ac: add -Wl,-rpath=path to $gmplibs
> 	* configure: Re-generate.

This is wrong.  Not everybody wants RPATHs randomly added, the path
could be already searched by the dynamic linker, or it can be configured
against libgmp etc. in one path only to be later on moved to some path where
it will be searched by the dynamic linker.
So, whether to use -Wl,-rpath or not (you aren't testing at all whether
the compiler and linker support -Wl,-rpath, e.g. if you don't use gcc as
the initial compiler, it might not work, or if your linker doesn't) should
be decided based on configure options.

	Jakub
Mike Stump - Jan. 17, 2013, 7:26 p.m.
On Jan 17, 2013, at 11:11 AM, minux.ma@gmail.com wrote:
> I assume all the linkers that gcc bootstraps with have support for
> the -rpath flag.

I don't know that that is true either.
Mike Stump - Jan. 17, 2013, 7:39 p.m.
On Jan 17, 2013, at 11:11 AM, minux.ma@gmail.com wrote:
> some systems (notably NetBSD), doesn't place the path where libgmp,

I think gcc should try and build and run a gmp program and fail to configure if the binary can't also run.  This prevents configuring and building on such a system.  The gcc directions for building gmp and friends should say that they must be configured and built with --disable-shared --enable-static if the user doesn't have the installed lib directory in their environment.
minux.ma@gmail.com - Jan. 17, 2013, 8:05 p.m.
On Fri, Jan 18, 2013 at 3:39 AM, Mike Stump <mikestump@comcast.net> wrote:
> On Jan 17, 2013, at 11:11 AM, minux.ma@gmail.com wrote:
>> some systems (notably NetBSD), doesn't place the path where libgmp,
>
> I think gcc should try and build and run a gmp program and fail to configure if the binary can't also run.  This prevents configuring and building on such a system.  The gcc directions for building gmp and friends should say that they must be configured and built with --disable-shared --enable-static if the user doesn't have the installed lib directory in their environment.

any opinions on this? this is very easy to implement with AC_TRY_RUN and
at least it will make the problem turn up early instead of when it's about to
configure libgcc (with the confusing error "gcc not able to compile").
of course, i will exclude the case when we're cross compiling gcc.

I'm happy to leave the problem of setting -rpath to pkgsrc maintainers
as I just want to do a full gcc bootstrap to test another libgcc patch.
Paolo Bonzini - Jan. 18, 2013, 8:17 a.m.
Il 17/01/2013 21:05, minux ha scritto:
>> >
>> > I think gcc should try and build and run a gmp program and fail to configure if the binary can't also run.  This prevents configuring and building on such a system.  The gcc directions for building gmp and friends should say that they must be configured and built with --disable-shared --enable-static if the user doesn't have the installed lib directory in their environment.
> any opinions on this? this is very easy to implement with AC_TRY_RUN and
> at least it will make the problem turn up early instead of when it's about to
> configure libgcc (with the confusing error "gcc not able to compile").
> of course, i will exclude the case when we're cross compiling gcc.

It's not confusing, it's right.  gcc is not able to compile indeed.

> I'm happy to leave the problem of setting -rpath to pkgsrc maintainers
> as I just want to do a full gcc bootstrap to test another libgcc patch.

I think it is user error.  If your libraries are not in the right place,
either you rely on .la files and force everyone to use libtool (not a
good idea), or you put the paths in LD_LIBRARY_PATH/LD_RUN_PATH, or you
add flags manually to the configure line.

Paolo
Mike Stump - Jan. 18, 2013, 5:48 p.m.
On Jan 17, 2013, at 12:05 PM, minux <minux.ma@gmail.com> wrote:
> On Fri, Jan 18, 2013 at 3:39 AM, Mike Stump <mikestump@comcast.net> wrote:
>> On Jan 17, 2013, at 11:11 AM, minux.ma@gmail.com wrote:
>>> some systems (notably NetBSD), doesn't place the path where libgmp,
>> 
>> I think gcc should try and build and run a gmp program and fail to configure if the binary can't also run.  This prevents configuring and building on such a system.  The gcc directions for building gmp and friends should say that they must be configured and built with --disable-shared --enable-static if the user doesn't have the installed lib directory in their environment.
> 
> any opinions on this? this is very easy to implement with AC_TRY_RUN and
> at least it will make the problem turn up early instead of when it's about to
> configure libgcc (with the confusing error "gcc not able to compile").
> of course, i will exclude the case when we're cross compiling gcc.

I don't think that's a wise idea (to exclude the cross compiling case).  The notion is, we need to preflight the sanity (since some people are insane) of the libraries.  If we find they are insane, in any way, then we can't use them, period.  At no time, did I mention the word cross, therefore, it is wrong to insert it.

Now, if a library isn't used for cross compilation, then trivially, the check should be avoided for cross; but that isn't the case here.

?

Now, I'm happy to have a shared library expert weigh in and explain why we should not fail the build…  I'm happy to defer to them, if there is a compelling reason why someone would compile things this way.  I just can't help but think we serve the user more by insisting up front, on being able to find the libraries at run time.

Oh, wait, AC_TRY_RUN, ac doesn't like cross…  must exclude cross, cause ac doesn't do cross…  if that was the motivation…  oh, I get it now.  Hum…  only a full canadian cross should pose a problem.  In a normal cross, one can still run on the host, as it is the same as the build machine…  Yeah, unfortunate…  but, ok, I agree with that.  I'd rather have the check, if only applicable to a subset; though, if there is a way to manage the full solution, that would be preferred.
Paolo Bonzini - Jan. 19, 2013, 1:45 p.m.
Il 18/01/2013 18:48, Mike Stump ha scritto:
> Now, I'm happy to have a shared library expert weigh in and explain
> why we should not fail the build…  I'm happy to defer to them, if
> there is a compelling reason why someone would compile things this
> way.  I just can't help but think we serve the user more by insisting
> up front, on being able to find the libraries at run time.

Because to some extent we expect the user to know what he's doing.  We
cannot cater for any mistake, and that's what this is.  A mismatch
between the link-time path and LD_RUN_PATH/LD_LIBRARY_PATH is simply a
mistake.

Paolo

Patch

Index: configure.ac
===================================================================
--- configure.ac	(revision 195265)
+++ configure.ac	(working copy)
@@ -1382,14 +1382,14 @@ 


  if test "x$with_gmp" != x; then
-  gmplibs="-L$with_gmp/lib $gmplibs"
+  gmplibs="-L$with_gmp/lib -Wl,-rpath=$with_gmp/lib $gmplibs"
    gmpinc="-I$with_gmp/include $gmpinc"
  fi
  if test "x$with_gmp_include" != x; then
    gmpinc="-I$with_gmp_include $gmpinc"
  fi
  if test "x$with_gmp_lib" != x; then
-  gmplibs="-L$with_gmp_lib $gmplibs"
+  gmplibs="-L$with_gmp_lib -Wl,-rpath=$with_gmp_lib $gmplibs"
  fi
  if test "x$with_gmp$with_gmp_include$with_gmp_lib" = x && test -d  
${srcdir}/gmp; then
    gmplibs='-L$$r/$(HOST_SUBDIR)/gmp/'"$lt_cv_objdir $gmplibs"
Index: configure
===================================================================
--- configure	(revision 195265)
+++ configure	(working copy)
@@ -5409,14 +5409,14 @@ 


  if test "x$with_gmp" != x; then
-  gmplibs="-L$with_gmp/lib $gmplibs"
+  gmplibs="-L$with_gmp/lib -Wl,-rpath=$with_gmp/lib $gmplibs"
    gmpinc="-I$with_gmp/include $gmpinc"
  fi
  if test "x$with_gmp_include" != x; then
    gmpinc="-I$with_gmp_include $gmpinc"
  fi
  if test "x$with_gmp_lib" != x; then
-  gmplibs="-L$with_gmp_lib $gmplibs"
+  gmplibs="-L$with_gmp_lib -Wl,-rpath=$with_gmp_lib $gmplibs"
  fi
  if test "x$with_gmp$with_gmp_include$with_gmp_lib" = x && test -d  
${srcdir}/gmp; then