vdso_standalone_test_x86.c build failure on Linus' tree

vdso_standalone_test_x86.c build failure on Linus' tree

[Josh Boyer]

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 <pefoley2@pefoley.com>
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 <pefoley2@pefoley.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>


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

Re: vdso_standalone_test_x86.c build failure on Linus' tree

[Andy Lutomirski]

On Wed, Oct 8, 2014 at 11:52 AM, Josh Boyer <jwboyer@fedoraproject.org> 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 <pefoley2@pefoley.com>
> 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 <pefoley2@pefoley.com>
>     Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>     Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>
>
> 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

Re: vdso_standalone_test_x86.c build failure on Linus' tree

[Peter Foley]

On Wed, Oct 8, 2014 at 3:16 PM, Andy Lutomirski <luto@amacapital.net> 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.

Re: vdso_standalone_test_x86.c build failure on Linus' tree

[Chuck Ebbert]

On Wed, 8 Oct 2014 12:16:11 -0700
Andy Lutomirski <luto@amacapital.net> wrote:

> On Wed, Oct 8, 2014 at 11:52 AM, Josh Boyer <jwboyer@fedoraproject.org> 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.

Re: vdso_standalone_test_x86.c build failure on Linus' tree

[Andy Lutomirski]

On Wed, Oct 8, 2014 at 1:46 PM, Chuck Ebbert <cebbert.lkml@gmail.com> wrote:
> On Wed, 8 Oct 2014 12:16:11 -0700
> Andy Lutomirski <luto@amacapital.net> wrote:
>
>> On Wed, Oct 8, 2014 at 11:52 AM, Josh Boyer <jwboyer@fedoraproject.org> 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

Re: vdso_standalone_test_x86.c build failure on Linus' tree

[H. Peter Anvin]

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

Re: vdso_standalone_test_x86.c build failure on Linus' tree

[Chuck Ebbert]

On Wed, 08 Oct 2014 13:55:00 -0700
"H. Peter Anvin" <hpa@zytor.com> 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...

Re: vdso_standalone_test_x86.c build failure on Linus' tree

[H. Peter Anvin]

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

Re: vdso_standalone_test_x86.c build failure on Linus' tree

[Chuck Ebbert]

On Wed, 08 Oct 2014 14:21:00 -0700
"H. Peter Anvin" <hpa@zytor.com> 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.

Re: vdso_standalone_test_x86.c build failure on Linus' tree

[Peter Foley]

On Wed, Oct 8, 2014 at 5:21 PM, H. Peter Anvin <hpa@zytor.com> 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/

Re: vdso_standalone_test_x86.c build failure on Linus' tree

[Andy Lutomirski]

On Wed, Oct 8, 2014 at 4:11 PM, Peter Foley <pefoley2@pefoley.com> wrote:
> On Wed, Oct 8, 2014 at 5:21 PM, H. Peter Anvin <hpa@zytor.com> 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

Re: vdso_standalone_test_x86.c build failure on Linus' tree

[Randy Dunlap]

On 10/08/14 16:18, Andy Lutomirski wrote:
> On Wed, Oct 8, 2014 at 4:11 PM, Peter Foley <pefoley2@pefoley.com> wrote:
>> On Wed, Oct 8, 2014 at 5:21 PM, H. Peter Anvin <hpa@zytor.com> 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

Re: vdso_standalone_test_x86.c build failure on Linus' tree

[Josh Boyer]

On Wed, Oct 8, 2014 at 5:09 PM, Chuck Ebbert <cebbert.lkml@gmail.com> wrote:
> On Wed, 08 Oct 2014 13:55:00 -0700
> "H. Peter Anvin" <hpa@zytor.com> 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