| Message ID | 20131211004908.GA19241@rox.home.comstyle.com |
|---|---|
| State | New |
| Headers | show |
On 10/12/13 7:49 PM, Brad Smith wrote: > This resolves the build issue with building the ROMs on OpenBSD on x86 archs. > As of OpenBSD 5.3 the compiler builds PIE binaries by default and thus the > whole OS/packages and so forth. The ROMs need to have PIE disabled. This > is my initial attempt at trying to get somehting upstream so that QEMU > both builds out of the box and to resolve the build issue with the > buildbots that has been around for awhile. We have a patch in our ports > tree but it is just the flags hardcoded into the Makefile which obviously > is not appropriate for upstream. > > From the OpenBSD buildbots.. > Building optionrom/multiboot.img > ld: multiboot.o: relocation R_X86_64_16 can not be used when making a shared object; recompile with -fPIC > > Signed-off by: Brad Smith <brad@comstyle.com> ping. > --- > > Change in v2: > * Fix '==' is not portable syntax. > > Change in v3: > * Rename variables and use compile_prog to detect the presence of the compiler/linker > flags, as suggested by Stefan Weil. > > diff --git a/configure b/configure > index 5d82283..89ae89d 100755 > --- a/configure > +++ b/configure > @@ -1365,6 +1365,11 @@ EOF > pie="no" > fi > fi > + > + if compile_prog "-fno-pie" "-nopie"; then > + CFLAGS_NOPIE="-fno-pie" > + LDFLAGS_NOPIE="-nopie" > + fi > fi > > ########################################## > @@ -4320,6 +4325,7 @@ echo "LD=$ld" >> $config_host_mak > echo "WINDRES=$windres" >> $config_host_mak > echo "LIBTOOL=$libtool" >> $config_host_mak > echo "CFLAGS=$CFLAGS" >> $config_host_mak > +echo "CFLAGS_NOPIE=$CFLAGS_NOPIE" >> $config_host_mak > echo "QEMU_CFLAGS=$QEMU_CFLAGS" >> $config_host_mak > echo "QEMU_INCLUDES=$QEMU_INCLUDES" >> $config_host_mak > if test "$sparse" = "yes" ; then > @@ -4333,6 +4339,7 @@ else > echo "AUTOCONF_HOST := " >> $config_host_mak > fi > echo "LDFLAGS=$LDFLAGS" >> $config_host_mak > +echo "LDFLAGS_NOPIE=$LDFLAGS_NOPIE" >> $config_host_mak > echo "LIBTOOLFLAGS=$LIBTOOLFLAGS" >> $config_host_mak > echo "LIBS+=$LIBS" >> $config_host_mak > echo "LIBS_TOOLS+=$libs_tools" >> $config_host_mak > diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile > index 57d8bd0..ce4852a 100644 > --- a/pc-bios/optionrom/Makefile > +++ b/pc-bios/optionrom/Makefile > @@ -12,6 +12,7 @@ $(call set-vpath, $(SRC_PATH)/pc-bios/optionrom) > CFLAGS := -Wall -Wstrict-prototypes -Werror -fomit-frame-pointer -fno-builtin > CFLAGS += -I$(SRC_PATH) > CFLAGS += $(call cc-option, $(CFLAGS), -fno-stack-protector) > +CFLAGS += $(CFLAGS_NOPIE) > QEMU_CFLAGS = $(CFLAGS) > > build-all: multiboot.bin linuxboot.bin kvmvapic.bin > @@ -20,7 +21,7 @@ build-all: multiboot.bin linuxboot.bin kvmvapic.bin > .SECONDARY: > > %.img: %.o > - $(call quiet-command,$(LD) -Ttext 0 -e _start -s -o $@ $<," Building $(TARGET_DIR)$@") > + $(call quiet-command,$(LD) $(LDFLAGS_NOPIE) -Ttext 0 -e _start -s -o $@ $<," Building $(TARGET_DIR)$@") > > %.raw: %.img > $(call quiet-command,$(OBJCOPY) -O binary -j .text $< $@," Building $(TARGET_DIR)$@") >
On 14/12/13 11:27 PM, Brad Smith wrote: > On 10/12/13 7:49 PM, Brad Smith wrote: >> This resolves the build issue with building the ROMs on OpenBSD on x86 >> archs. >> As of OpenBSD 5.3 the compiler builds PIE binaries by default and thus >> the >> whole OS/packages and so forth. The ROMs need to have PIE disabled. This >> is my initial attempt at trying to get somehting upstream so that QEMU >> both builds out of the box and to resolve the build issue with the >> buildbots that has been around for awhile. We have a patch in our ports >> tree but it is just the flags hardcoded into the Makefile which obviously >> is not appropriate for upstream. >> >> From the OpenBSD buildbots.. >> Building optionrom/multiboot.img >> ld: multiboot.o: relocation R_X86_64_16 can not be used when making a >> shared object; recompile with -fPIC >> >> Signed-off by: Brad Smith <brad@comstyle.com> > > ping. ping ping. >> --- >> >> Change in v2: >> * Fix '==' is not portable syntax. >> >> Change in v3: >> * Rename variables and use compile_prog to detect the presence of >> the compiler/linker >> flags, as suggested by Stefan Weil. >> >> diff --git a/configure b/configure >> index 5d82283..89ae89d 100755 >> --- a/configure >> +++ b/configure >> @@ -1365,6 +1365,11 @@ EOF >> pie="no" >> fi >> fi >> + >> + if compile_prog "-fno-pie" "-nopie"; then >> + CFLAGS_NOPIE="-fno-pie" >> + LDFLAGS_NOPIE="-nopie" >> + fi >> fi >> >> ########################################## >> @@ -4320,6 +4325,7 @@ echo "LD=$ld" >> $config_host_mak >> echo "WINDRES=$windres" >> $config_host_mak >> echo "LIBTOOL=$libtool" >> $config_host_mak >> echo "CFLAGS=$CFLAGS" >> $config_host_mak >> +echo "CFLAGS_NOPIE=$CFLAGS_NOPIE" >> $config_host_mak >> echo "QEMU_CFLAGS=$QEMU_CFLAGS" >> $config_host_mak >> echo "QEMU_INCLUDES=$QEMU_INCLUDES" >> $config_host_mak >> if test "$sparse" = "yes" ; then >> @@ -4333,6 +4339,7 @@ else >> echo "AUTOCONF_HOST := " >> >> $config_host_mak >> fi >> echo "LDFLAGS=$LDFLAGS" >> $config_host_mak >> +echo "LDFLAGS_NOPIE=$LDFLAGS_NOPIE" >> $config_host_mak >> echo "LIBTOOLFLAGS=$LIBTOOLFLAGS" >> $config_host_mak >> echo "LIBS+=$LIBS" >> $config_host_mak >> echo "LIBS_TOOLS+=$libs_tools" >> $config_host_mak >> diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile >> index 57d8bd0..ce4852a 100644 >> --- a/pc-bios/optionrom/Makefile >> +++ b/pc-bios/optionrom/Makefile >> @@ -12,6 +12,7 @@ $(call set-vpath, $(SRC_PATH)/pc-bios/optionrom) >> CFLAGS := -Wall -Wstrict-prototypes -Werror -fomit-frame-pointer >> -fno-builtin >> CFLAGS += -I$(SRC_PATH) >> CFLAGS += $(call cc-option, $(CFLAGS), -fno-stack-protector) >> +CFLAGS += $(CFLAGS_NOPIE) >> QEMU_CFLAGS = $(CFLAGS) >> >> build-all: multiboot.bin linuxboot.bin kvmvapic.bin >> @@ -20,7 +21,7 @@ build-all: multiboot.bin linuxboot.bin kvmvapic.bin >> .SECONDARY: >> >> %.img: %.o >> - $(call quiet-command,$(LD) -Ttext 0 -e _start -s -o $@ $<," >> Building $(TARGET_DIR)$@") >> + $(call quiet-command,$(LD) $(LDFLAGS_NOPIE) -Ttext 0 -e _start -s >> -o $@ $<," Building $(TARGET_DIR)$@") >> >> %.raw: %.img >> $(call quiet-command,$(OBJCOPY) -O binary -j .text $< $@," >> Building $(TARGET_DIR)$@") >> > >
On Tue, Dec 10, 2013 at 07:49:08PM -0500, Brad Smith wrote: > This resolves the build issue with building the ROMs on OpenBSD on x86 archs. > As of OpenBSD 5.3 the compiler builds PIE binaries by default and thus the > whole OS/packages and so forth. The ROMs need to have PIE disabled. This > is my initial attempt at trying to get somehting upstream so that QEMU > both builds out of the box and to resolve the build issue with the > buildbots that has been around for awhile. We have a patch in our ports > tree but it is just the flags hardcoded into the Makefile which obviously > is not appropriate for upstream. > > From the OpenBSD buildbots.. > Building optionrom/multiboot.img > ld: multiboot.o: relocation R_X86_64_16 can not be used when making a shared object; recompile with -fPIC > > Signed-off by: Brad Smith <brad@comstyle.com> > --- > > Change in v2: > * Fix '==' is not portable syntax. > > Change in v3: > * Rename variables and use compile_prog to detect the presence of the compiler/linker > flags, as suggested by Stefan Weil. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
On 12/20/13 06:19, Brad Smith wrote: > On 14/12/13 11:27 PM, Brad Smith wrote: >> On 10/12/13 7:49 PM, Brad Smith wrote: >>> This resolves the build issue with building the ROMs on OpenBSD on x86 >>> archs. >>> As of OpenBSD 5.3 the compiler builds PIE binaries by default and thus >>> the >>> whole OS/packages and so forth. The ROMs need to have PIE disabled. >>> This >>> is my initial attempt at trying to get somehting upstream so that QEMU >>> both builds out of the box and to resolve the build issue with the >>> buildbots that has been around for awhile. We have a patch in our ports >>> tree but it is just the flags hardcoded into the Makefile which >>> obviously >>> is not appropriate for upstream. >>> >>> From the OpenBSD buildbots.. >>> Building optionrom/multiboot.img >>> ld: multiboot.o: relocation R_X86_64_16 can not be used when making a >>> shared object; recompile with -fPIC >>> >>> Signed-off by: Brad Smith <brad@comstyle.com> >> >> ping. > > ping ping. ping ping ping.
Il 26/01/2014 02:37, Brad Smith ha scritto: >>> >> >> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> > > Is there some sort of process I am missing to have build fixes > commited so that QEMU actually builds? Right now we have problems getting patches committed at all. This patch and the other NetBSD patch is not lost. Paolo
On 26/01/14 1:06 PM, Paolo Bonzini wrote: > Il 26/01/2014 02:37, Brad Smith ha scritto: >>>> >>> >>> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> >> >> Is there some sort of process I am missing to have build fixes >> commited so that QEMU actually builds? > > Right now we have problems getting patches committed at all. > > This patch and the other NetBSD patch is not lost. I know it is not literally lost. I don't follow the list that closely.. what was the reason for there being two incidents over the last 2 months of there being no commits for over a week (at least from the perspective of git.qemu.org)?
On Sun, Jan 26, 2014 at 1:40 PM, Brad Smith <brad@comstyle.com> wrote: > On 26/01/14 1:06 PM, Paolo Bonzini wrote: >> >> Il 26/01/2014 02:37, Brad Smith ha scritto: >>>>> >>>>> >>>> >>>> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> >>> >>> >>> Is there some sort of process I am missing to have build fixes >>> commited so that QEMU actually builds? >> >> >> Right now we have problems getting patches committed at all. >> >> This patch and the other NetBSD patch is not lost. > > > I know it is not literally lost. > > I don't follow the list that closely.. what was the reason > for there being two incidents over the last 2 months of there > being no commits for over a week (at least from the perspective > of git.qemu.org)? Historically, having multiple committers has avoided this problem because when one person gets bogged down, there's someone else to step up. Right now, it seems all current committers are in a bogged down state. I've added another committer, Peter Maydell, to try to break the log jam. I'll try to devote more time to applying patches but hopefully with Peter's help too, we can get things moving at the appropriate speed again. Regards, Anthony Liguori > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > >
On 26/01/14 5:12 PM, Anthony Liguori wrote: > On Sun, Jan 26, 2014 at 1:40 PM, Brad Smith <brad@comstyle.com> wrote: >> On 26/01/14 1:06 PM, Paolo Bonzini wrote: >>> >>> Il 26/01/2014 02:37, Brad Smith ha scritto: >>>>>> >>>>>> >>>>> >>>>> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> >>>> >>>> >>>> Is there some sort of process I am missing to have build fixes >>>> commited so that QEMU actually builds? >>> >>> >>> Right now we have problems getting patches committed at all. >>> >>> This patch and the other NetBSD patch is not lost. >> >> >> I know it is not literally lost. >> >> I don't follow the list that closely.. what was the reason >> for there being two incidents over the last 2 months of there >> being no commits for over a week (at least from the perspective >> of git.qemu.org)? > > Historically, having multiple committers has avoided this problem > because when one person gets bogged down, there's someone else to step > up. > > Right now, it seems all current committers are in a bogged down state. > > I've added another committer, Peter Maydell, to try to break the log > jam. I'll try to devote more time to applying patches but hopefully > with Peter's help too, we can get things moving at the appropriate > speed again. Ok, I see. Thank you for the response.
On 26/01/14 1:06 PM, Paolo Bonzini wrote: > Il 26/01/2014 02:37, Brad Smith ha scritto: >>>> >>> >>> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> >> >> Is there some sort of process I am missing to have build fixes >> commited so that QEMU actually builds? > > Right now we have problems getting patches committed at all. > > This patch and the other NetBSD patch is not lost. > > Paolo ping.
On 16 February 2014 22:00, Brad Smith <brad@comstyle.com> wrote: > On 26/01/14 1:06 PM, Paolo Bonzini wrote: >> >> Il 26/01/2014 02:37, Brad Smith ha scritto: >>>>> >>>>> >>>> >>>> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> >>> >>> >>> Is there some sort of process I am missing to have build fixes >>> commited so that QEMU actually builds? >> >> >> Right now we have problems getting patches committed at all. >> >> This patch and the other NetBSD patch is not lost. >> >> Paolo > > > ping. Applied, thanks. Apologies for the delays. -- PMM
On 17/02/14 11:20 AM, Peter Maydell wrote: > On 16 February 2014 22:00, Brad Smith <brad@comstyle.com> wrote: >> On 26/01/14 1:06 PM, Paolo Bonzini wrote: >>> >>> Il 26/01/2014 02:37, Brad Smith ha scritto: >>>>>> >>>>>> >>>>> >>>>> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> >>>> >>>> >>>> Is there some sort of process I am missing to have build fixes >>>> commited so that QEMU actually builds? >>> >>> >>> Right now we have problems getting patches committed at all. >>> >>> This patch and the other NetBSD patch is not lost. >>> >>> Paolo >> >> >> ping. > > Applied, thanks. Apologies for the delays. Thank you very much. Just one issue... just curious why my last name is missing from the commit?
On 18 February 2014 00:36, Brad Smith <brad@comstyle.com> wrote: > Just one issue... just curious why my last name is missing > from the commit? Ah, we've run into a bug in patchwork. I downloaded your patch: http://patchwork.ozlabs.org/patch/299656/ but patchwork reconstructs patch mboxes from its database rather than just returning the original email, and it has a bug where it will always remember the name used by the very first email it ever saw from you. I guess it has a patch in the system way back from you with a misconfigured fullname. Sorry about that. I know they've discussed this issue on the patchwork mailing list but they obviously haven't implemented a fix yet. thanks -- PMM
On 18/02/14 4:45 AM, Peter Maydell wrote: > On 18 February 2014 00:36, Brad Smith <brad@comstyle.com> wrote: >> Just one issue... just curious why my last name is missing >> from the commit? > > Ah, we've run into a bug in patchwork. I downloaded your patch: > http://patchwork.ozlabs.org/patch/299656/ > > but patchwork reconstructs patch mboxes from its database > rather than just returning the original email, and it has a bug > where it will always remember the name used by the very > first email it ever saw from you. I guess it has a patch in > the system way back from you with a misconfigured fullname. > Sorry about that. I know they've discussed this issue on the > patchwork mailing list but they obviously haven't implemented > a fix yet. Well, it was intentionally left out back then but that was quite awhile ago. I have changed my e-mail setup since then to include the last name. Anyway, thanks for looking into this.
diff --git a/configure b/configure index 5d82283..89ae89d 100755 --- a/configure +++ b/configure @@ -1365,6 +1365,11 @@ EOF pie="no" fi fi + + if compile_prog "-fno-pie" "-nopie"; then + CFLAGS_NOPIE="-fno-pie" + LDFLAGS_NOPIE="-nopie" + fi fi ########################################## @@ -4320,6 +4325,7 @@ echo "LD=$ld" >> $config_host_mak echo "WINDRES=$windres" >> $config_host_mak echo "LIBTOOL=$libtool" >> $config_host_mak echo "CFLAGS=$CFLAGS" >> $config_host_mak +echo "CFLAGS_NOPIE=$CFLAGS_NOPIE" >> $config_host_mak echo "QEMU_CFLAGS=$QEMU_CFLAGS" >> $config_host_mak echo "QEMU_INCLUDES=$QEMU_INCLUDES" >> $config_host_mak if test "$sparse" = "yes" ; then @@ -4333,6 +4339,7 @@ else echo "AUTOCONF_HOST := " >> $config_host_mak fi echo "LDFLAGS=$LDFLAGS" >> $config_host_mak +echo "LDFLAGS_NOPIE=$LDFLAGS_NOPIE" >> $config_host_mak echo "LIBTOOLFLAGS=$LIBTOOLFLAGS" >> $config_host_mak echo "LIBS+=$LIBS" >> $config_host_mak echo "LIBS_TOOLS+=$libs_tools" >> $config_host_mak diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile index 57d8bd0..ce4852a 100644 --- a/pc-bios/optionrom/Makefile +++ b/pc-bios/optionrom/Makefile @@ -12,6 +12,7 @@ $(call set-vpath, $(SRC_PATH)/pc-bios/optionrom) CFLAGS := -Wall -Wstrict-prototypes -Werror -fomit-frame-pointer -fno-builtin CFLAGS += -I$(SRC_PATH) CFLAGS += $(call cc-option, $(CFLAGS), -fno-stack-protector) +CFLAGS += $(CFLAGS_NOPIE) QEMU_CFLAGS = $(CFLAGS) build-all: multiboot.bin linuxboot.bin kvmvapic.bin @@ -20,7 +21,7 @@ build-all: multiboot.bin linuxboot.bin kvmvapic.bin .SECONDARY: %.img: %.o - $(call quiet-command,$(LD) -Ttext 0 -e _start -s -o $@ $<," Building $(TARGET_DIR)$@") + $(call quiet-command,$(LD) $(LDFLAGS_NOPIE) -Ttext 0 -e _start -s -o $@ $<," Building $(TARGET_DIR)$@") %.raw: %.img $(call quiet-command,$(OBJCOPY) -O binary -j .text $< $@," Building $(TARGET_DIR)$@")
This resolves the build issue with building the ROMs on OpenBSD on x86 archs. As of OpenBSD 5.3 the compiler builds PIE binaries by default and thus the whole OS/packages and so forth. The ROMs need to have PIE disabled. This is my initial attempt at trying to get somehting upstream so that QEMU both builds out of the box and to resolve the build issue with the buildbots that has been around for awhile. We have a patch in our ports tree but it is just the flags hardcoded into the Makefile which obviously is not appropriate for upstream. From the OpenBSD buildbots.. Building optionrom/multiboot.img ld: multiboot.o: relocation R_X86_64_16 can not be used when making a shared object; recompile with -fPIC Signed-off by: Brad Smith <brad@comstyle.com> --- Change in v2: * Fix '==' is not portable syntax. Change in v3: * Rename variables and use compile_prog to detect the presence of the compiler/linker flags, as suggested by Stefan Weil.