[PATCH] build: add -Wl,-rpath=path to $gmplibs

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

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

[minux1, 2013-01-17 19:11:12]

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.

[jakub_redhat.com, 2013-01-17 19:16:53]

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

[mikestump_comcast.net, 2013-01-17 19:26:18]

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.

[minux1, 2013-01-17 19:27:27]

On Fri, Jan 18, 2013 at 3:16 AM, Jakub Jelinek <jakub@redhat.com> wrote:

> 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.
>
ok. how about this, we explicitly test whether a program linked with gmp
could
run or not? if not, try add -rpath and see if it works?
at least this could handle the case where we're using gcc.

[mikestump_comcast.net, 2013-01-17 19:39:22]

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.

[minux1, 2013-01-17 20:05:51]

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.

[bonzini_gnu.org, 2013-01-18 08:17:23]

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

[mikestump_comcast.net, 2013-01-18 17:48:59]

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.

[bonzini_gnu.org, 2013-01-19 13:45:07]

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