* s390-linux fails to build
@ 2015-07-23 12:18 Nick Clifton
2015-07-23 12:33 ` Jakub Jelinek
0 siblings, 1 reply; 8+ messages in thread
From: Nick Clifton @ 2015-07-23 12:18 UTC (permalink / raw)
To: hpenner@de.ibm.com uweigand, Andreas.Krebbel, Ulrich Weigand; +Cc: gcc-patches
Hi Helmut, Hi Ulrich, Hi Andreas,
A toolchain configured as --target=s390-linux currently fails to build
gcc because of an undefined function:
undefined reference to `s390_host_detect_local_cpu(int, char const**)'
Makefile:1858: recipe for target 'xgcc' failed
The patch below fixes the problem for me by adding a stub function in
s390-common.c, but I am not sure if it is the correct solution.
Please can you advise ?
Cheers
Nick
Index: gcc/common/config/s390/s390-common.c
===================================================================
--- gcc/common/config/s390/s390-common.c (revision 226094)
+++ gcc/common/config/s390/s390-common.c (working copy)
@@ -119,6 +119,14 @@
}
}
+const char * s390_host_detect_local_cpu (int, const char **)
__attribute__((weak));
+const char *
+s390_host_detect_local_cpu (int argc ATTRIBUTE_UNUSED,
+ const char **argv ATTRIBUTE_UNUSED)
+{
+ return NULL;
+}
+
#undef TARGET_DEFAULT_TARGET_FLAGS
#define TARGET_DEFAULT_TARGET_FLAGS (TARGET_DEFAULT)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: s390-linux fails to build
2015-07-23 12:18 s390-linux fails to build Nick Clifton
@ 2015-07-23 12:33 ` Jakub Jelinek
2015-07-23 12:56 ` Ulrich Weigand
0 siblings, 1 reply; 8+ messages in thread
From: Jakub Jelinek @ 2015-07-23 12:33 UTC (permalink / raw)
To: Nick Clifton; +Cc: Andreas.Krebbel, Ulrich Weigand, gcc-patches
On Thu, Jul 23, 2015 at 01:03:19PM +0100, Nick Clifton wrote:
> Hi Helmut, Hi Ulrich, Hi Andreas,
>
> A toolchain configured as --target=s390-linux currently fails to build
> gcc because of an undefined function:
>
> undefined reference to `s390_host_detect_local_cpu(int, char const**)'
> Makefile:1858: recipe for target 'xgcc' failed
>
> The patch below fixes the problem for me by adding a stub function in
> s390-common.c, but I am not sure if it is the correct solution.
> Please can you advise ?
Isn't it better to just follow what other arches do?
E.g. on i?86/x86_64, the EXTRA_SPEC_FUNCTIONS definition is guarded
with
#if defined(__i386__) || defined(__x86_64__)
and similarly on mips:
#if defined(__mips__)
and thus I'd expect s390{,x} should guard it with
#if defined(__s390__) || defined(__s390x__)
or so.
The config.host change also looks wrong, e.g. i?86 or mips have:
i[34567]86-*-* \
| x86_64-*-* )
case ${target} in
i[34567]86-*-* \
| x86_64-*-* )
host_extra_gcc_objs="driver-i386.o"
host_xmake_file="${host_xmake_file} i386/x-i386"
;;
esac
;;
mips*-*-linux*)
case ${target} in
mips*-*-linux*)
host_extra_gcc_objs="driver-native.o"
host_xmake_file="${host_xmake_file} mips/x-native"
;;
esac
;;
while s390 has:
s390-*-* | s390x-*-*)
host_extra_gcc_objs="driver-native.o"
host_xmake_file="${host_xmake_file} s390/x-native"
;;
I bet that is gone break also cross-compilers from s390* to other targets.
Jakub
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: s390-linux fails to build
2015-07-23 12:33 ` Jakub Jelinek
@ 2015-07-23 12:56 ` Ulrich Weigand
2015-07-23 13:09 ` Jakub Jelinek
0 siblings, 1 reply; 8+ messages in thread
From: Ulrich Weigand @ 2015-07-23 12:56 UTC (permalink / raw)
To: jakub; +Cc: Nick Clifton, Andreas.Krebbel, gcc-patches
Jakub Jelinek wrote:
> On Thu, Jul 23, 2015 at 01:03:19PM +0100, Nick Clifton wrote:
> > Hi Helmut, Hi Ulrich, Hi Andreas,
> >
> > A toolchain configured as --target=s390-linux currently fails to build
> > gcc because of an undefined function:
> >
> > undefined reference to `s390_host_detect_local_cpu(int, char const**)'
> > Makefile:1858: recipe for target 'xgcc' failed
> >
> > The patch below fixes the problem for me by adding a stub function in
> > s390-common.c, but I am not sure if it is the correct solution.
> > Please can you advise ?
>
> Isn't it better to just follow what other arches do?
> E.g. on i?86/x86_64, the EXTRA_SPEC_FUNCTIONS definition is guarded
> with
> #if defined(__i386__) || defined(__x86_64__)
> and similarly on mips:
> #if defined(__mips__)
> and thus I'd expect s390{,x} should guard it with
> #if defined(__s390__) || defined(__s390x__)
> or so.
This is supposed to be fixed by this pending patch:
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01546.html
(which hasn't been applied yet, but probably should be soon ...)
> The config.host change also looks wrong, e.g. i?86 or mips have:
> i[34567]86-*-* \
> | x86_64-*-* )
> case ${target} in
> i[34567]86-*-* \
> | x86_64-*-* )
> host_extra_gcc_objs="driver-i386.o"
> host_xmake_file="${host_xmake_file} i386/x-i386"
> ;;
> esac
> ;;
> mips*-*-linux*)
> case ${target} in
> mips*-*-linux*)
> host_extra_gcc_objs="driver-native.o"
> host_xmake_file="${host_xmake_file} mips/x-native"
> ;;
> esac
> ;;
> while s390 has:
> s390-*-* | s390x-*-*)
> host_extra_gcc_objs="driver-native.o"
> host_xmake_file="${host_xmake_file} s390/x-native"
> ;;
> I bet that is gone break also cross-compilers from s390* to other targets.
I think this should be fine on s390. The problem with i386 is that
the driver-native.c file uses data types only defined by the i386
target files (e.g. enum processor_type). But on s390, the file does
not any target-specific types and should be fully portable.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: s390-linux fails to build
2015-07-23 12:56 ` Ulrich Weigand
@ 2015-07-23 13:09 ` Jakub Jelinek
2015-07-23 13:26 ` Ulrich Weigand
0 siblings, 1 reply; 8+ messages in thread
From: Jakub Jelinek @ 2015-07-23 13:09 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: Nick Clifton, Andreas.Krebbel, gcc-patches
On Thu, Jul 23, 2015 at 02:46:43PM +0200, Ulrich Weigand wrote:
> This is supposed to be fixed by this pending patch:
> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01546.html
LGTM.
> > The config.host change also looks wrong, e.g. i?86 or mips have:
> > i[34567]86-*-* \
> > | x86_64-*-* )
> > case ${target} in
> > i[34567]86-*-* \
> > | x86_64-*-* )
> > host_extra_gcc_objs="driver-i386.o"
> > host_xmake_file="${host_xmake_file} i386/x-i386"
> > ;;
> > esac
> > ;;
> > mips*-*-linux*)
> > case ${target} in
> > mips*-*-linux*)
> > host_extra_gcc_objs="driver-native.o"
> > host_xmake_file="${host_xmake_file} mips/x-native"
> > ;;
> > esac
> > ;;
> > while s390 has:
> > s390-*-* | s390x-*-*)
> > host_extra_gcc_objs="driver-native.o"
> > host_xmake_file="${host_xmake_file} s390/x-native"
> > ;;
> > I bet that is gone break also cross-compilers from s390* to other targets.
>
> I think this should be fine on s390. The problem with i386 is that
> the driver-native.c file uses data types only defined by the i386
> target files (e.g. enum processor_type). But on s390, the file does
> not any target-specific types and should be fully portable.
That hunk means that driver-native.o is added to EXTRA_GCC_OBJS
even say for s390x-*-* -> x86_64-*-* compiler. While it might compile
there, nothing will use it, so what is it good for?
i?86/x86_64 backend will certainly not reference s390_host_detect_local_cpu
anywhere.
Jakub
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: s390-linux fails to build
2015-07-23 13:09 ` Jakub Jelinek
@ 2015-07-23 13:26 ` Ulrich Weigand
2015-07-23 13:31 ` Jakub Jelinek
0 siblings, 1 reply; 8+ messages in thread
From: Ulrich Weigand @ 2015-07-23 13:26 UTC (permalink / raw)
To: jakub; +Cc: Nick Clifton, Andreas.Krebbel, gcc-patches
Jakub Jelinek wrote:
> On Thu, Jul 23, 2015 at 02:46:43PM +0200, Ulrich Weigand wrote:
> > > I bet that is gone break also cross-compilers from s390* to other targets.
> >
> > I think this should be fine on s390. The problem with i386 is that
> > the driver-native.c file uses data types only defined by the i386
> > target files (e.g. enum processor_type). But on s390, the file does
> > not any target-specific types and should be fully portable.
>
> That hunk means that driver-native.o is added to EXTRA_GCC_OBJS
> even say for s390x-*-* -> x86_64-*-* compiler. While it might compile
> there, nothing will use it, so what is it good for?
> i?86/x86_64 backend will certainly not reference s390_host_detect_local_cpu
> anywhere.
Oh, I agree this will not be *used*. I just wanted to point out that it
will not *break* cross-compilers as is.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: s390-linux fails to build
2015-07-23 13:26 ` Ulrich Weigand
@ 2015-07-23 13:31 ` Jakub Jelinek
2015-07-23 13:44 ` Dominik Vogt
0 siblings, 1 reply; 8+ messages in thread
From: Jakub Jelinek @ 2015-07-23 13:31 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: Nick Clifton, Andreas.Krebbel, gcc-patches
On Thu, Jul 23, 2015 at 03:03:29PM +0200, Ulrich Weigand wrote:
> Jakub Jelinek wrote:
> > On Thu, Jul 23, 2015 at 02:46:43PM +0200, Ulrich Weigand wrote:
> > > > I bet that is gone break also cross-compilers from s390* to other targets.
> > >
> > > I think this should be fine on s390. The problem with i386 is that
> > > the driver-native.c file uses data types only defined by the i386
> > > target files (e.g. enum processor_type). But on s390, the file does
> > > not any target-specific types and should be fully portable.
> >
> > That hunk means that driver-native.o is added to EXTRA_GCC_OBJS
> > even say for s390x-*-* -> x86_64-*-* compiler. While it might compile
> > there, nothing will use it, so what is it good for?
> > i?86/x86_64 backend will certainly not reference s390_host_detect_local_cpu
> > anywhere.
>
> Oh, I agree this will not be *used*. I just wanted to point out that it
> will not *break* cross-compilers as is.
I think it would be better for consistency and sanity do what other
targets do, even if it won't break the cross-compilation.
Do you agree?
Jakub
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: s390-linux fails to build
2015-07-23 13:31 ` Jakub Jelinek
@ 2015-07-23 13:44 ` Dominik Vogt
2015-07-24 8:48 ` Dominik Vogt
0 siblings, 1 reply; 8+ messages in thread
From: Dominik Vogt @ 2015-07-23 13:44 UTC (permalink / raw)
To: gcc-patches; +Cc: Ulrich Weigand, Nick Clifton, Andreas.Krebbel, jakub
On Thu, Jul 23, 2015 at 03:09:46PM +0200, Jakub Jelinek wrote:
> On Thu, Jul 23, 2015 at 03:03:29PM +0200, Ulrich Weigand wrote:
> > Oh, I agree this will not be *used*. I just wanted to point out that it
> > will not *break* cross-compilers as is.
>
> I think it would be better for consistency and sanity do what other
> targets do, even if it won't break the cross-compilation.
> Do you agree?
It's certainly better to not compile a file with code that was
written to run on a different platform. I'll make a patch in a
couple of days.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: s390-linux fails to build
2015-07-23 13:44 ` Dominik Vogt
@ 2015-07-24 8:48 ` Dominik Vogt
0 siblings, 0 replies; 8+ messages in thread
From: Dominik Vogt @ 2015-07-24 8:48 UTC (permalink / raw)
To: gcc-patches; +Cc: Ulrich Weigand, Nick Clifton, Andreas.Krebbel, jakub
On Thu, Jul 23, 2015 at 03:03:29PM +0200, Ulrich Weigand wrote:
> Oh, I agree this will not be *used*. I just wanted to point out that it
> will not *break* cross-compilers as is.
I've just verified that cross compilation *does* work at the
moment with the patches quoted in some earlier post. (Andreas
will commit them shortly.)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-07-24 8:43 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-23 12:18 s390-linux fails to build Nick Clifton
2015-07-23 12:33 ` Jakub Jelinek
2015-07-23 12:56 ` Ulrich Weigand
2015-07-23 13:09 ` Jakub Jelinek
2015-07-23 13:26 ` Ulrich Weigand
2015-07-23 13:31 ` Jakub Jelinek
2015-07-23 13:44 ` Dominik Vogt
2015-07-24 8:48 ` Dominik Vogt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).