| Message ID | alpine.LNX.2.00.1312091143490.2197@tuna.site |
|---|---|
| State | New |
| Headers | show |
Il 09/12/2013 11:46, Gerald Pfeifer ha scritto: > Hmm, it looks like this has not been approved/applied, but I also > have not seen any NACK. > > This does address an annoying (and hard for novices to understand) > roadblock for someone installing GCC manually. Can this go in? I'm not sure why this should be different for x86_64 compared to all other bi-arch toolchains? I think the right place for this is a "Non-bugs" section in the installation manual. Paolo
> I'm not sure why this should be different for x86_64 compared to all > other bi-arch toolchains? It’s not, but it’s a particularly common one and has been reported multiple times here and on gcc-help. If we can help these users early, we spare ourselves the time to reply to such reports. (Also, documentation and this patch are not exclusive: in fact, I have also submitted a doc patch to make things clearer.) > I think the right place for this is a "Non-bugs" section in the > installation manual. Look at this as a diagnostics bug: our current diagnostics for this pretty common situation sucks. It comes late in the compilation, and the message itself isn’t helpful. FX
On Mon, 9 Dec 2013, FX wrote: > Look at this as a diagnostics bug: our current diagnostics for this > pretty common situation sucks. It comes late in the compilation, and > the message itself isn’t helpful. Totally seconded. Paolo, I have been running into this myself and was confused at first. If that happens to me, building GCC for some 20 years, imagine a new user. This is really something to be identified at configure time, with a reasonable error message. If FX's specific patch is not ideal yet, can you help rework it? That would be great. Gerald
On 12/09/2013 02:46 AM, Gerald Pfeifer wrote: > Hmm, it looks like this has not been approved/applied, but I also > have not seen any NACK. > > This does address an annoying (and hard for novices to understand) > roadblock for someone installing GCC manually. Can this go in? The patch looks ok to me. Totally agreed with down-thread re avoiding messages to gcc-help for the 99%. r~
Il 09/12/2013 12:08, Gerald Pfeifer ha scritto: > On Mon, 9 Dec 2013, FX wrote: >> > Look at this as a diagnostics bug: our current diagnostics for this >> > pretty common situation sucks. It comes late in the compilation, and >> > the message itself isn’t helpful. > Totally seconded. > > Paolo, I have been running into this myself and was confused at > first. If that happens to me, building GCC for some 20 years, > imagine a new user. > > This is really something to be identified at configure time, > with a reasonable error message. > > If FX's specific patch is not ideal yet, can you help rework it? > That would be great. The patch is okay, but if other architecture maintainers could add similar checks for their ports (SPARC and PPC, I guess), it would be nice. Paolo
> The patch is okay, but if other architecture maintainers could add > similar checks for their ports (SPARC and PPC, I guess), it would be nice. Thanks, committed as rev. 205975 Adding other systems to the list of checks will be easy, once the maintainers confirm that they want to opt in into it. FX
On Fri, Dec 13, 2013 at 10:47 PM, FX <fxcoudert@gmail.com> wrote: >> The patch is okay, but if other architecture maintainers could add >> similar checks for their ports (SPARC and PPC, I guess), it would be nice. > > Thanks, committed as rev. 205975 > > Adding other systems to the list of checks will be easy, once the maintainers confirm that they want to opt in into it. In our default build environment for package building GCC no longer builds because of this: [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.8/libgcc.a when sea rching for -lgcc [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ ld: cannot find -lgcc [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.8/libgcc_s.so when searching for -lgcc_s [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lgcc_s [ 152s] collect2: error: ld returned 1 exit status [ 152s] configure: error: I suspect your system does not have 32-bit developement libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib. the issue is that while we do have 32bit glibc support installed but not all required files for the host compiler to produce 32bit executables - which isn't needed - the compiler we bootstrap will have all the support for this. In fact, a x86_64 multilib GCC can be just bootstrapped fine with a non-multilib x86_64 compiler which you also disallow with the above check. I don't see how you can do this configure check in its current form early, before you've built the stage1 compiler. So - please consider reverting this patch or at least provide a way to override the check. Thanks, Richard. > FX
On Fri, Jan 31, 2014 at 3:33 PM, Richard Biener <richard.guenther@gmail.com> wrote: > On Fri, Dec 13, 2013 at 10:47 PM, FX <fxcoudert@gmail.com> wrote: >>> The patch is okay, but if other architecture maintainers could add >>> similar checks for their ports (SPARC and PPC, I guess), it would be nice. >> >> Thanks, committed as rev. 205975 >> >> Adding other systems to the list of checks will be easy, once the maintainers confirm that they want to opt in into it. > > In our default build environment for package building GCC no longer builds > because of this: > > [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ > ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.8/libgcc.a when sea > rching for -lgcc > [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ > ld: cannot find -lgcc > [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: > skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.8/libgcc_s.so > when searching for -lgcc_s > [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: > cannot find -lgcc_s > [ 152s] collect2: error: ld returned 1 exit status > [ 152s] configure: error: I suspect your system does not have 32-bit > developement libraries (libc and headers). If you have them, rerun > configure with --enable-multilib. If you do not have them, and want to > build a 64-bit-only compiler, rerun configure with --disable-multilib. > > the issue is that while we do have 32bit glibc support installed but not all > required files for the host compiler to produce 32bit executables - which > isn't needed - the compiler we bootstrap will have all the support for this. > > In fact, a x86_64 multilib GCC can be just bootstrapped fine with a > non-multilib x86_64 compiler which you also disallow with the above check. > > I don't see how you can do this configure check in its current form early, > before you've built the stage1 compiler. > > So - please consider reverting this patch or at least provide a way to > override the check. I've just seen that an explicit --enable-multilib is a way to do that. Still I think this is odd behavior - as you are matching x86_64-*linux you can as well check for /usr/include/gnu/stub{,-64}.h. I don't know of any distribution where you can have the header package installed without the corresponding libraries. Richard. > Thanks, > Richard. > > > >> FX
On Fri, Jan 31, 2014 at 3:40 PM, Richard Biener <richard.guenther@gmail.com> wrote: > On Fri, Jan 31, 2014 at 3:33 PM, Richard Biener > <richard.guenther@gmail.com> wrote: >> On Fri, Dec 13, 2013 at 10:47 PM, FX <fxcoudert@gmail.com> wrote: >>>> The patch is okay, but if other architecture maintainers could add >>>> similar checks for their ports (SPARC and PPC, I guess), it would be nice. >>> >>> Thanks, committed as rev. 205975 >>> >>> Adding other systems to the list of checks will be easy, once the maintainers confirm that they want to opt in into it. >> >> In our default build environment for package building GCC no longer builds >> because of this: >> >> [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ >> ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.8/libgcc.a when sea >> rching for -lgcc >> [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ >> ld: cannot find -lgcc >> [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: >> skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.8/libgcc_s.so >> when searching for -lgcc_s >> [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: >> cannot find -lgcc_s >> [ 152s] collect2: error: ld returned 1 exit status >> [ 152s] configure: error: I suspect your system does not have 32-bit >> developement libraries (libc and headers). If you have them, rerun >> configure with --enable-multilib. If you do not have them, and want to >> build a 64-bit-only compiler, rerun configure with --disable-multilib. >> >> the issue is that while we do have 32bit glibc support installed but not all >> required files for the host compiler to produce 32bit executables - which >> isn't needed - the compiler we bootstrap will have all the support for this. >> >> In fact, a x86_64 multilib GCC can be just bootstrapped fine with a >> non-multilib x86_64 compiler which you also disallow with the above check. >> >> I don't see how you can do this configure check in its current form early, >> before you've built the stage1 compiler. >> >> So - please consider reverting this patch or at least provide a way to >> override the check. > > I've just seen that an explicit --enable-multilib is a way to do that. > > Still I think this is odd behavior - as you are matching x86_64-*linux > you can as well check for /usr/include/gnu/stub{,-64}.h. I don't know > of any distribution where you can have the header package installed > without the corresponding libraries. Btw, doing the configure check exactly after all-stage1-gcc should be an early enough and a serialization point, no? There you can do the check even for when cross-compiling. Richard. > Richard. > >> Thanks, >> Richard. >> >> >> >>> FX
> I've just seen that an explicit --enable-multilib is a way to do that. Yes, I was writing that as a reply when I received your email. (Also, it’s written in the configure error message.) > Btw, doing the configure check exactly after all-stage1-gcc should be > an early enough and a serialization point, no? There you can do the > check even for when cross-compiling. Well, you’ve already built a whole stage, so it’s not so early, is it? FX
On Fri, Jan 31, 2014 at 3:45 PM, FX <fxcoudert@gmail.com> wrote: >> I've just seen that an explicit --enable-multilib is a way to do that. > > Yes, I was writing that as a reply when I received your email. (Also, it's written in the configure error message.) Yeah - you know, that message is quite long and somehow I didn't read it carefully. I suspect that will happen to others, too, so we'll get some extra complaints from that ;) >> Btw, doing the configure check exactly after all-stage1-gcc should be >> an early enough and a serialization point, no? There you can do the >> check even for when cross-compiling. > > Well, you've already built a whole stage, so it's not so early, is it? Well, building the stage1 compiler is probably the fastest thing nowadays (it didn't yet build the target libraries for stage1 with the stage1, unoptimized and checking-enabled compiler - which is where it would fail in the odd way which is what you want to improve). As I said, you can't "properly" check it at the point you are checking. Which is why I complain - you're not checking this properly! Anyway, I've fixed the "bug" on our side with --enable-multilib. Richard. > > FX
> As I said, you can't "properly" check it at the point you are checking. > Which is why I complain - you're not checking this properly! This is understood. There is a choice to be made, between an early check (which will benefit our casual users) catching this particular special case, and a later check. I argued for an earlier check, because it was a particular annoying and particularly un-user-friendly error, and wrote the check in a way to minimize the number of false negatives. But, as you say, it is not possible to write a perfect check at that early point. FX
On Fri, 31 Jan 2014, Richard Biener wrote: > Still I think this is odd behavior - as you are matching x86_64-*linux > you can as well check for /usr/include/gnu/stub{,-64}.h. I don't know On Ubuntu those are in /usr/include/x86_64-linux-gnu/gnu/ (and I suppose the 32-bit one is /usr/include/i386-linux-gnu/gnu/ but haven't checked).
On Fri, Jan 31, 2014 at 03:49:40PM +0100, Richard Biener wrote: > On Fri, Jan 31, 2014 at 3:45 PM, FX <fxcoudert@gmail.com> wrote: > >> I've just seen that an explicit --enable-multilib is a way to do that. > > > > Yes, I was writing that as a reply when I received your email. (Also, it's written in the configure error message.) > > Yeah - you know, that message is quite long and somehow I didn't read it > carefully. I suspect that will happen to others, too, so we'll get some > extra complaints from that ;) > > >> Btw, doing the configure check exactly after all-stage1-gcc should be > >> an early enough and a serialization point, no? There you can do the > >> check even for when cross-compiling. > > > > Well, you've already built a whole stage, so it's not so early, is it? > > Well, building the stage1 compiler is probably the fastest thing nowadays > (it didn't yet build the target libraries for stage1 with the stage1, > unoptimized > and checking-enabled compiler - which is where it would fail in the odd > way which is what you want to improve). > > As I said, you can't "properly" check it at the point you are checking. > Which is why I complain - you're not checking this properly! > > Anyway, I've fixed the "bug" on our side with --enable-multilib. Just hit the same thing, while I have (in mock) 32-bit devel libc installed, I don't have 32-bit libgcc_s installed (what for, it will be built by gcc). Please revert it, or at least improve it (e.g. by trying to build with -static-libgcc at least). Jakub
On Tue, Feb 11, 2014 at 5:17 PM, Jakub Jelinek <jakub@redhat.com> wrote: > On Fri, Jan 31, 2014 at 03:49:40PM +0100, Richard Biener wrote: >> On Fri, Jan 31, 2014 at 3:45 PM, FX <fxcoudert@gmail.com> wrote: >> >> I've just seen that an explicit --enable-multilib is a way to do that. >> > >> > Yes, I was writing that as a reply when I received your email. (Also, it's written in the configure error message.) >> >> Yeah - you know, that message is quite long and somehow I didn't read it >> carefully. I suspect that will happen to others, too, so we'll get some >> extra complaints from that ;) >> >> >> Btw, doing the configure check exactly after all-stage1-gcc should be >> >> an early enough and a serialization point, no? There you can do the >> >> check even for when cross-compiling. >> > >> > Well, you've already built a whole stage, so it's not so early, is it? >> >> Well, building the stage1 compiler is probably the fastest thing nowadays >> (it didn't yet build the target libraries for stage1 with the stage1, >> unoptimized >> and checking-enabled compiler - which is where it would fail in the odd >> way which is what you want to improve). >> >> As I said, you can't "properly" check it at the point you are checking. >> Which is why I complain - you're not checking this properly! >> >> Anyway, I've fixed the "bug" on our side with --enable-multilib. > > Just hit the same thing, while I have (in mock) 32-bit devel libc installed, > I don't have 32-bit libgcc_s installed (what for, it will be built by gcc). > > Please revert it, or at least improve it (e.g. by trying to build > with -static-libgcc at least). I wouldn't have static 32bit libgcc installed either. Richard.
On Wed, Feb 12, 2014 at 11:52:47AM +0100, Richard Biener wrote: > On Tue, Feb 11, 2014 at 5:17 PM, Jakub Jelinek <jakub@redhat.com> wrote: > > On Fri, Jan 31, 2014 at 03:49:40PM +0100, Richard Biener wrote: > >> On Fri, Jan 31, 2014 at 3:45 PM, FX <fxcoudert@gmail.com> wrote: > >> >> I've just seen that an explicit --enable-multilib is a way to do that. > >> > > >> > Yes, I was writing that as a reply when I received your email. (Also, it's written in the configure error message.) > >> > >> Yeah - you know, that message is quite long and somehow I didn't read it > >> carefully. I suspect that will happen to others, too, so we'll get some > >> extra complaints from that ;) > >> > >> >> Btw, doing the configure check exactly after all-stage1-gcc should be > >> >> an early enough and a serialization point, no? There you can do the > >> >> check even for when cross-compiling. > >> > > >> > Well, you've already built a whole stage, so it's not so early, is it? > >> > >> Well, building the stage1 compiler is probably the fastest thing nowadays > >> (it didn't yet build the target libraries for stage1 with the stage1, > >> unoptimized > >> and checking-enabled compiler - which is where it would fail in the odd > >> way which is what you want to improve). > >> > >> As I said, you can't "properly" check it at the point you are checking. > >> Which is why I complain - you're not checking this properly! > >> > >> Anyway, I've fixed the "bug" on our side with --enable-multilib. > > > > Just hit the same thing, while I have (in mock) 32-bit devel libc installed, > > I don't have 32-bit libgcc_s installed (what for, it will be built by gcc). > > > > Please revert it, or at least improve it (e.g. by trying to build > > with -static-libgcc at least). > > I wouldn't have static 32bit libgcc installed either. So perhaps turn that into a check if preprocessing of #include <features.h> works with -m32 (and never complain when building --with-sysroot*)? I mean, if features.h doesn't preprocess successfully (because of missing /usr/include/gnu/stubs-32.h), then as long as the compiler is going to include the same headers and not some sysroot, multilib building would fail in that case too. Jakub
On Wed, Feb 12, 2014 at 11:57 AM, Jakub Jelinek <jakub@redhat.com> wrote: > On Wed, Feb 12, 2014 at 11:52:47AM +0100, Richard Biener wrote: >> On Tue, Feb 11, 2014 at 5:17 PM, Jakub Jelinek <jakub@redhat.com> wrote: >> > On Fri, Jan 31, 2014 at 03:49:40PM +0100, Richard Biener wrote: >> >> On Fri, Jan 31, 2014 at 3:45 PM, FX <fxcoudert@gmail.com> wrote: >> >> >> I've just seen that an explicit --enable-multilib is a way to do that. >> >> > >> >> > Yes, I was writing that as a reply when I received your email. (Also, it's written in the configure error message.) >> >> >> >> Yeah - you know, that message is quite long and somehow I didn't read it >> >> carefully. I suspect that will happen to others, too, so we'll get some >> >> extra complaints from that ;) >> >> >> >> >> Btw, doing the configure check exactly after all-stage1-gcc should be >> >> >> an early enough and a serialization point, no? There you can do the >> >> >> check even for when cross-compiling. >> >> > >> >> > Well, you've already built a whole stage, so it's not so early, is it? >> >> >> >> Well, building the stage1 compiler is probably the fastest thing nowadays >> >> (it didn't yet build the target libraries for stage1 with the stage1, >> >> unoptimized >> >> and checking-enabled compiler - which is where it would fail in the odd >> >> way which is what you want to improve). >> >> >> >> As I said, you can't "properly" check it at the point you are checking. >> >> Which is why I complain - you're not checking this properly! >> >> >> >> Anyway, I've fixed the "bug" on our side with --enable-multilib. >> > >> > Just hit the same thing, while I have (in mock) 32-bit devel libc installed, >> > I don't have 32-bit libgcc_s installed (what for, it will be built by gcc). >> > >> > Please revert it, or at least improve it (e.g. by trying to build >> > with -static-libgcc at least). >> >> I wouldn't have static 32bit libgcc installed either. > > So perhaps turn that into a check if preprocessing of #include <features.h> > works with -m32 (and never complain when building --with-sysroot*)? > I mean, if features.h doesn't preprocess successfully (because of missing > /usr/include/gnu/stubs-32.h), then as long as the compiler is going to > include the same headers and not some sysroot, multilib building would fail > in that case too. That sounds good to me. Though it still wouldn't work with a non-multilib built host compiler (maybe detect that and just warn but not abort for that case?). Richard. > Jakub
Index: configure.ac =================================================================== --- configure.ac (revision 201292) +++ configure.ac (working copy) @@ -2861,6 +2861,26 @@ case "${target}" in ;; esac +# Special user-friendly check for native x86_64-linux build, if +# multilib is not explicitly enabled. +case "$target:$have_compiler:$host:$target:$enable_multilib" in + x86_64-*linux*:yes:$build:$build:) + # Make sure we have a developement environment that handles 32-bit + dev64=no + echo "int main () { return 0; }" > conftest.c + ${CC} -m32 -o conftest ${CFLAGS} ${CPPFLAGS} ${LDFLAGS} conftest.c + if test $? = 0 ; then + if test -s conftest || test -s conftest.exe ; then + dev64=yes + fi + fi + rm -f conftest* + if test x${dev64} != xyes ; then + AC_MSG_ERROR([I suspect your system does not have 32-bit developement libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib.]) + fi + ;; +esac + # Default to --enable-multilib. if test x${enable_multilib} = x ; then target_configargs="--enable-multilib ${target_configargs}"