| Message ID | 047d7b6d7cc0187e9504d380c271@google.com |
|---|---|
| State | New |
| Headers | show |
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
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.
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.
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.
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
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.
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
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
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"