I always have problems cross-compiling tools (I build everything on a 64-bit machine and generally target a 32-bit host), because all the link steps are missing targets. I''ve use this tiny patch on the base of my workspaces. To my knowledge, this doesn''t break anything -- but who knows with builds, particularly cross-compiling. I just thought I''d throw this there in case others have the same issue and it doesn''t affect standard build environments. diff -r a422e2a4451e config/x86_32.mk --- a/config/x86_32.mk +++ b/config/x86_32.mk @@ -8,6 +8,7 @@ CONFIG_XCUTILS := y CONFIG_IOEMU := y CFLAGS += -m32 -march=i686 +LDFLAGS += -m32 -march=i686 # Use only if calling $(LD) directly. LDFLAGS_DIRECT_OpenBSD = _obsd diff -r a422e2a4451e config/x86_64.mk --- a/config/x86_64.mk +++ b/config/x86_64.mk @@ -9,6 +9,7 @@ CONFIG_XCUTILS := y CONFIG_IOEMU := y CFLAGS += -m64 +LDFLAGS += -m64 LIBLEAFDIR = $(LIBLEAFDIR_x86_64) LIBDIR = $(LIBDIR_x86_64) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On 28.09.11 at 23:31, Adin Scannell <adin@gridcentric.com> wrote: > I always have problems cross-compiling tools (I build everything on a > 64-bit machine and generally target a 32-bit host), because all the > link steps are missing targets. I''ve use this tiny patch on the base > of my workspaces. > > To my knowledge, this doesn''t break anything -- but who knows with > builds, particularly cross-compiling. I just thought I''d throw this > there in case others have the same issue and it doesn''t affect > standard build environments.Are you saying this actually works for you (building everything, not just the tools)? I do cross builds too, but generally the other way around (64-bit build on 32-bit host), and hence need to only cross-build the hypervisor to put underneath everything.> diff -r a422e2a4451e config/x86_32.mk > --- a/config/x86_32.mk > +++ b/config/x86_32.mk > @@ -8,6 +8,7 @@ CONFIG_XCUTILS := y > CONFIG_IOEMU := y > > CFLAGS += -m32 -march=i686 > +LDFLAGS += -m32 -march=i686I can''t seem to find an ld (native or cross) that would accept -m32, -march=i686, ...> > # Use only if calling $(LD) directly. > LDFLAGS_DIRECT_OpenBSD = _obsd > diff -r a422e2a4451e config/x86_64.mk > --- a/config/x86_64.mk > +++ b/config/x86_64.mk > @@ -9,6 +9,7 @@ CONFIG_XCUTILS := y > CONFIG_IOEMU := y > > CFLAGS += -m64 > +LDFLAGS += -m64... or -m64. But $(LDFLAGS) gets passed to $(LD) when building Xen (other than for the tools, where generally $(CC) is used to do the linking). Jan> > LIBLEAFDIR = $(LIBLEAFDIR_x86_64) > LIBDIR = $(LIBDIR_x86_64)_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Sep-29 07:55 UTC
Re: [Xen-devel] [PATCH] build fixes for cross-compiling
On Wed, 2011-09-28 at 22:31 +0100, Adin Scannell wrote:> I always have problems cross-compiling tools (I build everything on a > 64-bit machine and generally target a 32-bit host), because all the > link steps are missing targets. I''ve use this tiny patch on the base > of my workspaces. > > To my knowledge, this doesn''t break anything -- but who knows with > builds, particularly cross-compiling. I just thought I''d throw this > there in case others have the same issue and it doesn''t affect > standard build environments.FWIW Linux does approximately the same thing. It uses it''s cc-option construct in the m32 case (presumably once upon a time non-biarch 32 bit compilers were common) but given that we already use -m32 unconditionally in CFLAGS I guess we don''t care now. I don''t actually do cross compiles myself (only because it doesn''t work... so maybe now I will) but this didn''t break my native 32 bit tools or native 64 bit Xen build so: Acked-by: Ian Campbell <ian.campbell@citrix.com> (I suppose this change is small enough not to require> > > diff -r a422e2a4451e config/x86_32.mk > --- a/config/x86_32.mk > +++ b/config/x86_32.mk > @@ -8,6 +8,7 @@ CONFIG_XCUTILS := y > CONFIG_IOEMU := y > > CFLAGS += -m32 -march=i686 > +LDFLAGS += -m32 -march=i686 > > # Use only if calling $(LD) directly. > LDFLAGS_DIRECT_OpenBSD = _obsd > diff -r a422e2a4451e config/x86_64.mk > --- a/config/x86_64.mk > +++ b/config/x86_64.mk > @@ -9,6 +9,7 @@ CONFIG_XCUTILS := y > CONFIG_IOEMU := y > > CFLAGS += -m64 > +LDFLAGS += -m64 > > LIBLEAFDIR = $(LIBLEAFDIR_x86_64) > LIBDIR = $(LIBDIR_x86_64)_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Sep-29 08:00 UTC
Re: [Xen-devel] [PATCH] build fixes for cross-compiling
On Thu, 2011-09-29 at 08:43 +0100, Jan Beulich wrote:> >>> On 28.09.11 at 23:31, Adin Scannell <adin@gridcentric.com> wrote: > > I always have problems cross-compiling tools (I build everything on a > > 64-bit machine and generally target a 32-bit host), because all the > > link steps are missing targets. I''ve use this tiny patch on the base > > of my workspaces. > > > > To my knowledge, this doesn''t break anything -- but who knows with > > builds, particularly cross-compiling. I just thought I''d throw this > > there in case others have the same issue and it doesn''t affect > > standard build environments. > > Are you saying this actually works for you (building everything, not just > the tools)? > > I do cross builds too, but generally the other way around (64-bit > build on 32-bit host), and hence need to only cross-build the > hypervisor to put underneath everything. > > > diff -r a422e2a4451e config/x86_32.mk > > --- a/config/x86_32.mk > > +++ b/config/x86_32.mk > > @@ -8,6 +8,7 @@ CONFIG_XCUTILS := y > > CONFIG_IOEMU := y > > > > CFLAGS += -m32 -march=i686 > > +LDFLAGS += -m32 -march=i686 > > I can''t seem to find an ld (native or cross) that would accept -m32, > -march=i686, ... > > > > > # Use only if calling $(LD) directly. > > LDFLAGS_DIRECT_OpenBSD = _obsd > > diff -r a422e2a4451e config/x86_64.mk > > --- a/config/x86_64.mk > > +++ b/config/x86_64.mk > > @@ -9,6 +9,7 @@ CONFIG_XCUTILS := y > > CONFIG_IOEMU := y > > > > CFLAGS += -m64 > > +LDFLAGS += -m64 > > ... or -m64. But $(LDFLAGS) gets passed to $(LD) when building Xen > (other than for the tools, where generally $(CC) is used to do the > linking).This worked for me, the link line ends up as ld -m64 -melf_x86_64 -T xen.lds -N prelink.o \ /local/scratch/ianc/devel/xen-unstable.hg/xen/.xen-x86_64-syms.1.o -o /local/scratch/ianc/devel/xen-unstable.hg/xen/xen-x86_64-syms (the inclusion of the arch in the filename is a local patch) This is with ld from Debian Squeeze: $ ld --version GNU ld (GNU Binutils for Debian) 2.20.1-system.20100303 Ah, I think I see what''s happening: the -melf... simply silently overrides the -m64, just "ld -m64" gives errors as you suggested, so does "ld -melf... -m64". We have LDFLAGS_DIRECT, adding LDFLAGS_INDIRECT seems a bit gross though... I wonder if perhaps LDFLAGS and LDFLAGS_DIRECT should be mut8lly exclusive, i.e. direct calls to the linker use only the latter and not both? Ian.> > Jan > > > > > LIBLEAFDIR = $(LIBLEAFDIR_x86_64) > > LIBDIR = $(LIBDIR_x86_64) > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On 29.09.11 at 10:00, Ian Campbell <Ian.Campbell@citrix.com> wrote: > We have LDFLAGS_DIRECT, adding LDFLAGS_INDIRECT seems a bit gross > though... I wonder if perhaps LDFLAGS and LDFLAGS_DIRECT should be > mut8lly exclusive, i.e. direct calls to the linker use only the latter > and not both?Actually I always found it wrong to read commands like "$(CC) $(LDFLAGS)" - imo xxxFLAGS should be passed exclusively to tool xxx. So rather than having LDFLAGS_DIRECT, I''d suggest cleaning this up and having e.g. CCLDFLAGS or CC_LINK_FLAGS or some such. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/09/2011 01:22, "Jan Beulich" <JBeulich@suse.com> wrote:>>>> On 29.09.11 at 10:00, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> We have LDFLAGS_DIRECT, adding LDFLAGS_INDIRECT seems a bit gross >> though... I wonder if perhaps LDFLAGS and LDFLAGS_DIRECT should be >> mut8lly exclusive, i.e. direct calls to the linker use only the latter >> and not both? > > Actually I always found it wrong to read commands like "$(CC) $(LDFLAGS)" > - imo xxxFLAGS should be passed exclusively to tool xxx. So rather than > having LDFLAGS_DIRECT, I''d suggest cleaning this up and having e.g. > CCLDFLAGS or CC_LINK_FLAGS or some such.Or perhaps we could arrange to only link via direct invocation of ld? Apart from the hassle of changing all our Makefiles, is there a good reason to use gcc as a linker wrapper? -- Keir> Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich writes ("Re: [Xen-devel] [PATCH] build fixes for cross-compiling"):> Ian Campbell <Ian.Campbell@citrix.com> wrote: > > We have LDFLAGS_DIRECT, adding LDFLAGS_INDIRECT seems a bit gross > > though... I wonder if perhaps LDFLAGS and LDFLAGS_DIRECT should be > > mut8lly exclusive, i.e. direct calls to the linker use only the latter > > and not both? > > Actually I always found it wrong to read commands like "$(CC) $(LDFLAGS)" > - imo xxxFLAGS should be passed exclusively to tool xxx. So rather than > having LDFLAGS_DIRECT, I''d suggest cleaning this up and having e.g. > CCLDFLAGS or CC_LINK_FLAGS or some such.Yes, I agree. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On 29.09.11 at 16:31, Keir Fraser <keir.xen@gmail.com> wrote: > On 29/09/2011 01:22, "Jan Beulich" <JBeulich@suse.com> wrote: > >>>>> On 29.09.11 at 10:00, Ian Campbell <Ian.Campbell@citrix.com> wrote: >>> We have LDFLAGS_DIRECT, adding LDFLAGS_INDIRECT seems a bit gross >>> though... I wonder if perhaps LDFLAGS and LDFLAGS_DIRECT should be >>> mut8lly exclusive, i.e. direct calls to the linker use only the latter >>> and not both? >> >> Actually I always found it wrong to read commands like "$(CC) $(LDFLAGS)" >> - imo xxxFLAGS should be passed exclusively to tool xxx. So rather than >> having LDFLAGS_DIRECT, I''d suggest cleaning this up and having e.g. >> CCLDFLAGS or CC_LINK_FLAGS or some such. > > Or perhaps we could arrange to only link via direct invocation of ld? Apart > from the hassle of changing all our Makefiles, is there a good reason to use > gcc as a linker wrapper?I''m afraid that would require manually specifying the crt*.o files as well as libgcc (if required) the compiler automatically tells the linker to include, which would be ugly (namely when it comes to supporting multiple host OSes). Imo, invoking the naked linker should generally be avoided when linking with any kind of system provided runtime library. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/09/2011 07:51, "Jan Beulich" <JBeulich@suse.com> wrote:>> Or perhaps we could arrange to only link via direct invocation of ld? Apart >> from the hassle of changing all our Makefiles, is there a good reason to use >> gcc as a linker wrapper? > > I''m afraid that would require manually specifying the crt*.o files as > well as libgcc (if required) the compiler automatically tells the linker to > include, which would be ugly (namely when it comes to supporting > multiple host OSes). Imo, invoking the naked linker should generally be > avoided when linking with any kind of system provided runtime library.Good point. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Adin Scannell
2011-Sep-30 21:14 UTC
Re: [Xen-devel] [PATCH] build fixes for cross-compiling
> Are you saying this actually works for you (building everything, not just > the tools)?To build everything, I need to tweak a couple of extra bits (in the attached patch). I''m somewhat wary about statements regarding anything build-related, because I know everyone has a different approach and it runs in a different environment. With the both first patch and the attached, everything builds for me for both XEN_TARGET_ARCH=x86_32 and x86_64 in my 64-bit environment.> I do cross builds too, but generally the other way around (64-bit > build on 32-bit host), and hence need to only cross-build the > hypervisor to put underneath everything. > > I can''t seem to find an ld (native or cross) that would accept -m32, > -march=i686, ...I think I had the same thing happen to me that happened to Ian (-m32 -melf_x86_64 ... so no errors). If the LDFLAGS / LDFLAGS_INDIRECT stuff is messy, my previous approach has been to add $(CFLAGS) to all the link steps in the tools (i.e. lib*, xl, etc.) so that the approach architecture flags would be passed to gcc for linking. I don''t mind going through and doing that until everything builds smoothly for 32-bit target on 64-bit, provided that''s a friendly solution. It would be great to be able to stop using a set of build patches at the bottom of my queue. :) Cheers, -Adin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On 30.09.11 at 23:14, Adin Scannell <adin@gridcentric.com> wrote: >> Are you saying this actually works for you (building everything, not just >> the tools)? > > To build everything, I need to tweak a couple of extra bits (in the > attached patch). I''m somewhat wary about statements regarding > anything build-related, because I know everyone has a different > approach and it runs in a different environment. With the both first > patch and the attached, everything builds for me for both > XEN_TARGET_ARCH=x86_32 and x86_64 in my 64-bit environment. > >> I do cross builds too, but generally the other way around (64-bit >> build on 32-bit host), and hence need to only cross-build the >> hypervisor to put underneath everything. >> >> I can''t seem to find an ld (native or cross) that would accept -m32, >> -march=i686, ... > > I think I had the same thing happen to me that happened to Ian (-m32 > -melf_x86_64 ... so no errors).Yeah, I realize that. But I''d nevertheless suggest not passing otherwise invalid options to any build tool, as them being ignored is likely more a bug than a feature (and ought to be considered subject to change at any time).> If the LDFLAGS / LDFLAGS_INDIRECT stuff is messy, my previous approach > has been to add $(CFLAGS) to all the link steps in the tools (i.e. > lib*, xl, etc.) so that the approach architecture flags would be > passed to gcc for linking. I don''t mind going through and doing thatPassing CFLAGS to the linking stage is as wrong as passing LDFLAGS to the compiler for the linking step. But it was apparently agreed to elsewhere in this thread to get this properly separated and cleaned up anyway.> until everything builds smoothly for 32-bit target on 64-bit, provided > that''s a friendly solution. It would be great to be able to stop using > a set of build patches at the bottom of my queue. :)I understand that (I have some build environment related changes at the end of my patch set too) - as long as the changes are not dependent upon something that is entirely specific to your env (some of mine are), proposing them for general inclusion is certainly reasonable. Some of what''s in the patch you had attached last even seemed more like a bug fix than a build one to me (though the tools aren''t my realm)... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel