I'm seeing the following build failure on a 32-bit x86 build in Fedora
based on Linux v3.17-2860-gef0625b70dac:
Documentation/vDSO/vdso_standalone_test_x86.o: In function `to_base10':
vdso_standalone_test_x86.c:(.text+0xcc): undefined reference to `__umoddi3'
vdso_standalone_test_x86.c:(.text+0xea): undefined reference to `__udivdi3'
collect2: error: ld returned 1 exit status
scripts/Makefile.host:100: recipe for target
'Documentation/vDSO/vdso_standalone_test_x86' failed
make[2]: *** [Documentation/vDSO/vdso_standalone_test_x86] Error 1
scripts/Makefile.build:404: recipe for target 'Documentation/vDSO' failed
make[1]: *** [Documentation/vDSO] Error 2
make[1]: *** Waiting for unfinished jobs....
Makefile:922: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 2
Looking at some of the git logs around this, it seems that
vdso_standalone_test_x86.c is 64-bit specific, so I was curious why it
was even being built on a 32-bit build. Seems this commit:
commit adb19fb66eeebac07fe37d968725bb8906dadb8e
Author: Peter Foley <[email protected]>
Date: Thu Sep 25 11:23:09 2014 -0700
Documentation: add makefiles for more targets
Add a bunch of previously unbuilt source files to the Documentation build
machinery.
Signed-off-by: Peter Foley <[email protected]>
Signed-off-by: Randy Dunlap <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
blindly added it to the build target.
So is vdso_standalone_test_x86.c really 64-bit specific? If so,
should that commit be reverted (or a hunk of it anyway), should there
be some mechanism to not build it on 32-bit, or should there be some
additional CFLAGS passed?
josh
Full build log here:
http://koji.fedoraproject.org/koji/getfile?taskID=7802438&name=build.log
On Wed, Oct 8, 2014 at 11:52 AM, Josh Boyer <[email protected]> wrote:
> I'm seeing the following build failure on a 32-bit x86 build in Fedora
> based on Linux v3.17-2860-gef0625b70dac:
>
> Documentation/vDSO/vdso_standalone_test_x86.o: In function `to_base10':
> vdso_standalone_test_x86.c:(.text+0xcc): undefined reference to `__umoddi3'
> vdso_standalone_test_x86.c:(.text+0xea): undefined reference to `__udivdi3'
> collect2: error: ld returned 1 exit status
> scripts/Makefile.host:100: recipe for target
> 'Documentation/vDSO/vdso_standalone_test_x86' failed
> make[2]: *** [Documentation/vDSO/vdso_standalone_test_x86] Error 1
> scripts/Makefile.build:404: recipe for target 'Documentation/vDSO' failed
> make[1]: *** [Documentation/vDSO] Error 2
> make[1]: *** Waiting for unfinished jobs....
> Makefile:922: recipe for target 'vmlinux' failed
> make: *** [vmlinux] Error 2
>
> Looking at some of the git logs around this, it seems that
> vdso_standalone_test_x86.c is 64-bit specific, so I was curious why it
> was even being built on a 32-bit build. Seems this commit:
>
> commit adb19fb66eeebac07fe37d968725bb8906dadb8e
> Author: Peter Foley <[email protected]>
> Date: Thu Sep 25 11:23:09 2014 -0700
>
> Documentation: add makefiles for more targets
>
> Add a bunch of previously unbuilt source files to the Documentation build
> machinery.
>
> Signed-off-by: Peter Foley <[email protected]>
> Signed-off-by: Randy Dunlap <[email protected]>
> Signed-off-by: Jiri Kosina <[email protected]>
>
>
> blindly added it to the build target.
>
> So is vdso_standalone_test_x86.c really 64-bit specific? If so,
> should that commit be reverted (or a hunk of it anyway), should there
> be some mechanism to not build it on 32-bit, or should there be some
> additional CFLAGS passed?
It should build and work on 32-bit.
Except that the makefile is totally bogus. vdso_standalone_test isn't
a hostprog at all. It's a target prog. But kbuild doesn't understand
that, so I have no idea what, if anything, that makefile is supposed
to do.
I would argue that the whole documentation build system should be
fixed to cross-compile or should just be disabled for cross-builds if
glibc isn't available.
FWIW, the comment at the top of vdso_standalone_test_x86.c documents
*exactly* how to build it, and it works if you build it like that.
--Andy
On Wed, Oct 8, 2014 at 3:16 PM, Andy Lutomirski <[email protected]> wrote:
> It should build and work on 32-bit.
>
> Except that the makefile is totally bogus. vdso_standalone_test isn't
> a hostprog at all. It's a target prog. But kbuild doesn't understand
> that, so I have no idea what, if anything, that makefile is supposed
> to do.
The idea is to increase build testing for targets in Documentation,
but I didn't really consider cross-compiling those targets.
>
> I would argue that the whole documentation build system should be
> fixed to cross-compile or should just be disabled for cross-builds if
> glibc isn't available.
It might make sense to just completely disable CONFIG_BUILD_DOCSRC if
we're cross-compiling.
>
> FWIW, the comment at the top of vdso_standalone_test_x86.c documents
> *exactly* how to build it, and it works if you build it like that.
So, it looks like 32bit needs -lgcc_s
I'll whip up a patch to add that.
On Wed, 8 Oct 2014 12:16:11 -0700
Andy Lutomirski <[email protected]> wrote:
> On Wed, Oct 8, 2014 at 11:52 AM, Josh Boyer <[email protected]> wrote:
> > I'm seeing the following build failure on a 32-bit x86 build in Fedora
> > based on Linux v3.17-2860-gef0625b70dac:
> >
> > Documentation/vDSO/vdso_standalone_test_x86.o: In function `to_base10':
> > vdso_standalone_test_x86.c:(.text+0xcc): undefined reference to `__umoddi3'
> > vdso_standalone_test_x86.c:(.text+0xea): undefined reference to `__udivdi3'
> > collect2: error: ld returned 1 exit status
> > scripts/Makefile.host:100: recipe for target
> > 'Documentation/vDSO/vdso_standalone_test_x86' failed
> > make[2]: *** [Documentation/vDSO/vdso_standalone_test_x86] Error 1
> > scripts/Makefile.build:404: recipe for target 'Documentation/vDSO' failed
> > make[1]: *** [Documentation/vDSO] Error 2
> > make[1]: *** Waiting for unfinished jobs....
> > Makefile:922: recipe for target 'vmlinux' failed
> > make: *** [vmlinux] Error 2
> >
> It should build and work on 32-bit.
>
> Except that the makefile is totally bogus. vdso_standalone_test isn't
> a hostprog at all. It's a target prog. But kbuild doesn't understand
> that, so I have no idea what, if anything, that makefile is supposed
> to do.
Heh, I was wondering why I got a 64-bit program with ARCH=i386
> I would argue that the whole documentation build system should be
> fixed to cross-compile or should just be disabled for cross-builds if
> glibc isn't available.
>
Fedora doesn't cross-compile i686 builds because of problems like
this. It sets up an i386 chroot and runs all native tools inside of
it.
On Wed, Oct 8, 2014 at 1:46 PM, Chuck Ebbert <[email protected]> wrote:
> On Wed, 8 Oct 2014 12:16:11 -0700
> Andy Lutomirski <[email protected]> wrote:
>
>> On Wed, Oct 8, 2014 at 11:52 AM, Josh Boyer <[email protected]> wrote:
>> > I'm seeing the following build failure on a 32-bit x86 build in Fedora
>> > based on Linux v3.17-2860-gef0625b70dac:
>> >
>> > Documentation/vDSO/vdso_standalone_test_x86.o: In function `to_base10':
>> > vdso_standalone_test_x86.c:(.text+0xcc): undefined reference to `__umoddi3'
>> > vdso_standalone_test_x86.c:(.text+0xea): undefined reference to `__udivdi3'
>> > collect2: error: ld returned 1 exit status
>> > scripts/Makefile.host:100: recipe for target
>> > 'Documentation/vDSO/vdso_standalone_test_x86' failed
>> > make[2]: *** [Documentation/vDSO/vdso_standalone_test_x86] Error 1
>> > scripts/Makefile.build:404: recipe for target 'Documentation/vDSO' failed
>> > make[1]: *** [Documentation/vDSO] Error 2
>> > make[1]: *** Waiting for unfinished jobs....
>> > Makefile:922: recipe for target 'vmlinux' failed
>> > make: *** [vmlinux] Error 2
>> >
>> It should build and work on 32-bit.
>>
>> Except that the makefile is totally bogus. vdso_standalone_test isn't
>> a hostprog at all. It's a target prog. But kbuild doesn't understand
>> that, so I have no idea what, if anything, that makefile is supposed
>> to do.
>
> Heh, I was wondering why I got a 64-bit program with ARCH=i386
Once kselftest takes off, we'll have lots of fun. In principle,
x86_64 kernels should pass the 32-bit tests, too :)
>
>> I would argue that the whole documentation build system should be
>> fixed to cross-compile or should just be disabled for cross-builds if
>> glibc isn't available.
>>
>
> Fedora doesn't cross-compile i686 builds because of problems like
> this. It sets up an i386 chroot and runs all native tools inside of
> it.
>
In this particular case, cross-compiling would have worked around the bug.
--Andy
On 10/08/2014 01:46 PM, Chuck Ebbert wrote:
>
> Fedora doesn't cross-compile i686 builds because of problems like
> this. It sets up an i386 chroot and runs all native tools inside of
> it.
>
Breaking cross-compilation is not okay, though, regardless of what
Fedora does. It should be okay to, for example, build an i386 kernel on
an ARM box.
-hpa
On Wed, 08 Oct 2014 13:55:00 -0700
"H. Peter Anvin" <[email protected]> wrote:
> On 10/08/2014 01:46 PM, Chuck Ebbert wrote:
> >
> > Fedora doesn't cross-compile i686 builds because of problems like
> > this. It sets up an i386 chroot and runs all native tools inside of
> > it.
> >
>
> Breaking cross-compilation is not okay, though, regardless of what
> Fedora does. It should be okay to, for example, build an i386 kernel on
> an ARM box.
>
I think they tried that for a while, and ended up chasing compiler
and makefile bugs all day. And then there's the software that wants
to run self-tests as part of its build...
On Wed, Oct 8, 2014 at 5:09 PM, Chuck Ebbert <[email protected]> wrote:
> On Wed, 08 Oct 2014 13:55:00 -0700
> "H. Peter Anvin" <[email protected]> wrote:
>
>> On 10/08/2014 01:46 PM, Chuck Ebbert wrote:
>> >
>> > Fedora doesn't cross-compile i686 builds because of problems like
>> > this. It sets up an i386 chroot and runs all native tools inside of
>> > it.
>> >
>>
>> Breaking cross-compilation is not okay, though, regardless of what
>> Fedora does. It should be okay to, for example, build an i386 kernel on
>> an ARM box.
>>
>
> I think they tried that for a while, and ended up chasing compiler
> and makefile bugs all day. And then there's the software that wants
> to run self-tests as part of its build...
The Fedora kernel package cross builds the other way (ARM on i386)
just fine. It might build ARM->i386 as well, but that's less useful.
At any rate, Peter is talking about the kernel, not software in
general.
josh
On 10/08/2014 02:09 PM, Chuck Ebbert wrote:
>>
>> Breaking cross-compilation is not okay, though, regardless of what
>> Fedora does. It should be okay to, for example, build an i386 kernel on
>> an ARM box.
>>
>
> I think they tried that for a while, and ended up chasing compiler
> and makefile bugs all day. And then there's the software that wants
> to run self-tests as part of its build...
>
That we can't solve, but it is not okay to break the kernel build.
-hpa
On Wed, 08 Oct 2014 14:21:00 -0700
"H. Peter Anvin" <[email protected]> wrote:
> On 10/08/2014 02:09 PM, Chuck Ebbert wrote:
> >>
> >> Breaking cross-compilation is not okay, though, regardless of what
> >> Fedora does. It should be okay to, for example, build an i386 kernel on
> >> an ARM box.
> >>
> >
> > I think they tried that for a while, and ended up chasing compiler
> > and makefile bugs all day. And then there's the software that wants
> > to run self-tests as part of its build...
> >
>
> That we can't solve, but it is not okay to break the kernel build.
>
Also, as Andy pointed out, when building for x86_64 we probably want
to build both 32-bit and 64-bit versions of most test programs like
this one.
On Wed, Oct 8, 2014 at 5:21 PM, H. Peter Anvin <[email protected]> wrote:
> That we can't solve, but it is not okay to break the kernel build.
Should I just make CONFIG_BUILD_DOCSRC depend on CROSS_COMPILE=""?
I'm not sure how much value would be added by implementing targetprogs
in kbuild, simply to increase build testing of Documentation/
On Wed, Oct 8, 2014 at 4:11 PM, Peter Foley <[email protected]> wrote:
> On Wed, Oct 8, 2014 at 5:21 PM, H. Peter Anvin <[email protected]> wrote:
>> That we can't solve, but it is not okay to break the kernel build.
>
> Should I just make CONFIG_BUILD_DOCSRC depend on CROSS_COMPILE=""?
> I'm not sure how much value would be added by implementing targetprogs
> in kbuild, simply to increase build testing of Documentation/
Yes, IMO. Let the kselftest people solve it, because they might have
extra requirements.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
On 10/08/14 16:18, Andy Lutomirski wrote:
> On Wed, Oct 8, 2014 at 4:11 PM, Peter Foley <[email protected]> wrote:
>> On Wed, Oct 8, 2014 at 5:21 PM, H. Peter Anvin <[email protected]> wrote:
>>> That we can't solve, but it is not okay to break the kernel build.
>>
>> Should I just make CONFIG_BUILD_DOCSRC depend on CROSS_COMPILE=""?
>> I'm not sure how much value would be added by implementing targetprogs
>> in kbuild, simply to increase build testing of Documentation/
>
> Yes, IMO. Let the kselftest people solve it, because they might have
> extra requirements.
>
> --Andy
As I have said in the past, there are probably lots of source files in
Documentation/ that should be in tools/ or tools/testing/ instead.
--
~Randy