In case of -pthread already exists in QEMU_CFLAGS,
compilation of sample pthread program successed,
but -pthread is not putting into PTHREAD_LIBS in this case.
PTHREAD_LIB is using while compiling tests/migration/stress.
Signed-off-by: Alexey Perevalov <a.perevalov@samsung.com>
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 6587e80..a2dd044 100755
--- a/configure
+++ b/configure
@@ -3359,6 +3359,7 @@ int main(void) {
EOF
if compile_prog "" "" ; then
pthread=yes
+ PTHREAD_LIB="-pthread"
else
for pthread_lib in $PTHREADLIBS_LIST; do
if compile_prog "" "$pthread_lib" ; then
--
2.7.4
On Fri, Sep 29, 2017 at 01:11:14PM +0300, Alexey Perevalov wrote: > In case of -pthread already exists in QEMU_CFLAGS, > compilation of sample pthread program successed, > but -pthread is not putting into PTHREAD_LIBS in this case. > PTHREAD_LIB is using while compiling tests/migration/stress. > > Signed-off-by: Alexey Perevalov <a.perevalov@samsung.com> > --- > configure | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure b/configure > index 6587e80..a2dd044 100755 > --- a/configure > +++ b/configure > @@ -3359,6 +3359,7 @@ int main(void) { > EOF > if compile_prog "" "" ; then > pthread=yes > + PTHREAD_LIB="-pthread" > else > for pthread_lib in $PTHREADLIBS_LIST; do > if compile_prog "" "$pthread_lib" ; then We shouldn't do this because it affects whole of QEMU. The stress program needs -lpthread because it is linking statically, so just add it to the Makefile rule for building stress. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 09/29/2017 01:40 PM, Daniel P. Berrange wrote: > On Fri, Sep 29, 2017 at 01:11:14PM +0300, Alexey Perevalov wrote: >> In case of -pthread already exists in QEMU_CFLAGS, >> compilation of sample pthread program successed, >> but -pthread is not putting into PTHREAD_LIBS in this case. >> PTHREAD_LIB is using while compiling tests/migration/stress. >> >> Signed-off-by: Alexey Perevalov <a.perevalov@samsung.com> >> --- >> configure | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/configure b/configure >> index 6587e80..a2dd044 100755 >> --- a/configure >> +++ b/configure >> @@ -3359,6 +3359,7 @@ int main(void) { >> EOF >> if compile_prog "" "" ; then >> pthread=yes >> + PTHREAD_LIB="-pthread" >> else >> for pthread_lib in $PTHREADLIBS_LIST; do >> if compile_prog "" "$pthread_lib" ; then > We shouldn't do this because it affects whole of QEMU. The stress program > needs -lpthread because it is linking statically, so just add it to the > Makefile rule for building stress. ok, but I didn't find any explicit usage of PTHREAD_LIB, and avoiding it in Makefile I think will make PTHREAD_LIB redundant. > > Regards, > Daniel -- Best regards, Alexey Perevalov
On Fri, Sep 29, 2017 at 03:52:34PM +0300, Alexey Perevalov wrote: > On 09/29/2017 01:40 PM, Daniel P. Berrange wrote: > > On Fri, Sep 29, 2017 at 01:11:14PM +0300, Alexey Perevalov wrote: > > > In case of -pthread already exists in QEMU_CFLAGS, > > > compilation of sample pthread program successed, > > > but -pthread is not putting into PTHREAD_LIBS in this case. > > > PTHREAD_LIB is using while compiling tests/migration/stress. > > > > > > Signed-off-by: Alexey Perevalov <a.perevalov@samsung.com> > > > --- > > > configure | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/configure b/configure > > > index 6587e80..a2dd044 100755 > > > --- a/configure > > > +++ b/configure > > > @@ -3359,6 +3359,7 @@ int main(void) { > > > EOF > > > if compile_prog "" "" ; then > > > pthread=yes > > > + PTHREAD_LIB="-pthread" > > > else > > > for pthread_lib in $PTHREADLIBS_LIST; do > > > if compile_prog "" "$pthread_lib" ; then > > We shouldn't do this because it affects whole of QEMU. The stress program > > needs -lpthread because it is linking statically, so just add it to the > > Makefile rule for building stress. > ok, but I didn't find any explicit usage of PTHREAD_LIB, > and avoiding it in Makefile I think will make PTHREAD_LIB > redundant. Oh yeah, actually PTHREAD_LIB is a variable i introduced specifically for the stress program, so my comment above is wrong and I think your patch is ok. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 09/29/2017 04:05 PM, Daniel P. Berrange wrote: > On Fri, Sep 29, 2017 at 03:52:34PM +0300, Alexey Perevalov wrote: >> On 09/29/2017 01:40 PM, Daniel P. Berrange wrote: >>> On Fri, Sep 29, 2017 at 01:11:14PM +0300, Alexey Perevalov wrote: >>>> In case of -pthread already exists in QEMU_CFLAGS, >>>> compilation of sample pthread program successed, >>>> but -pthread is not putting into PTHREAD_LIBS in this case. >>>> PTHREAD_LIB is using while compiling tests/migration/stress. >>>> >>>> Signed-off-by: Alexey Perevalov <a.perevalov@samsung.com> >>>> --- >>>> configure | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/configure b/configure >>>> index 6587e80..a2dd044 100755 >>>> --- a/configure >>>> +++ b/configure >>>> @@ -3359,6 +3359,7 @@ int main(void) { >>>> EOF >>>> if compile_prog "" "" ; then >>>> pthread=yes >>>> + PTHREAD_LIB="-pthread" >>>> else >>>> for pthread_lib in $PTHREADLIBS_LIST; do >>>> if compile_prog "" "$pthread_lib" ; then >>> We shouldn't do this because it affects whole of QEMU. The stress program >>> needs -lpthread because it is linking statically, so just add it to the >>> Makefile rule for building stress. >> ok, but I didn't find any explicit usage of PTHREAD_LIB, >> and avoiding it in Makefile I think will make PTHREAD_LIB >> redundant. > Oh yeah, actually PTHREAD_LIB is a variable i introduced specifically > for the stress program, so my comment above is wrong and I think your > patch is ok. in that hardcoded form or trying to generalize it somehow? -pthread comes to QEMU_CFLAGS from pkg-config --cflags for glib library so it's hard to say which one from list -pthread -lpthread -lpthreadGC2 really lead to success build of the sample. So it's better to cut pthread from QEMU_CFLAGS, or you thing it's overkill? > > > Regards, > Daniel -- Best regards, Alexey Perevalov
On Fri, Sep 29, 2017 at 04:47:01PM +0300, Alexey Perevalov wrote: > On 09/29/2017 04:05 PM, Daniel P. Berrange wrote: > > On Fri, Sep 29, 2017 at 03:52:34PM +0300, Alexey Perevalov wrote: > > > On 09/29/2017 01:40 PM, Daniel P. Berrange wrote: > > > > On Fri, Sep 29, 2017 at 01:11:14PM +0300, Alexey Perevalov wrote: > > > > > In case of -pthread already exists in QEMU_CFLAGS, > > > > > compilation of sample pthread program successed, > > > > > but -pthread is not putting into PTHREAD_LIBS in this case. > > > > > PTHREAD_LIB is using while compiling tests/migration/stress. > > > > > > > > > > Signed-off-by: Alexey Perevalov <a.perevalov@samsung.com> > > > > > --- > > > > > configure | 1 + > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > diff --git a/configure b/configure > > > > > index 6587e80..a2dd044 100755 > > > > > --- a/configure > > > > > +++ b/configure > > > > > @@ -3359,6 +3359,7 @@ int main(void) { > > > > > EOF > > > > > if compile_prog "" "" ; then > > > > > pthread=yes > > > > > + PTHREAD_LIB="-pthread" > > > > > else > > > > > for pthread_lib in $PTHREADLIBS_LIST; do > > > > > if compile_prog "" "$pthread_lib" ; then > > > > We shouldn't do this because it affects whole of QEMU. The stress program > > > > needs -lpthread because it is linking statically, so just add it to the > > > > Makefile rule for building stress. > > > ok, but I didn't find any explicit usage of PTHREAD_LIB, > > > and avoiding it in Makefile I think will make PTHREAD_LIB > > > redundant. > > Oh yeah, actually PTHREAD_LIB is a variable i introduced specifically > > for the stress program, so my comment above is wrong and I think your > > patch is ok. > in that hardcoded form or trying to generalize it somehow? > > -pthread comes to QEMU_CFLAGS from pkg-config --cflags for glib library > so it's hard to say which one from list -pthread -lpthread -lpthreadGC2 > really lead to success build of the sample. > So it's better to cut pthread from QEMU_CFLAGS, or you thing it's overkill? The stress program uses pthreads so we can't just cut it. We just need to set -pthread IMHO. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Hello Daniel, I decided just to use CC instead of swapping CXX and CC in LINKPROG, and keep PTHREAD_LIB untouched, once your decided previous patch is ok. Alexey Perevalov (1): Makefile: don't use LINKPROG for tests/migration/stress tests/Makefile.include | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.7.4
This patch just replaces LINKPROG for CC.
LINKPROG invokes both CXX and CC.
So in case of static linking of C source, static libstdc++
is required by build, but it could be missing in system.
And static libstdc++ may not be needed for whole QEMU.
Signed-off-by: Alexey Perevalov <a.perevalov@samsung.com>
---
tests/Makefile.include | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/Makefile.include b/tests/Makefile.include
index abc6707..bf94516 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -803,7 +803,7 @@ tests/numa-test$(EXESUF): tests/numa-test.o
tests/vmgenid-test$(EXESUF): tests/vmgenid-test.o tests/boot-sector.o tests/acpi-utils.o
tests/migration/stress$(EXESUF): tests/migration/stress.o
- $(call quiet-command, $(LINKPROG) -static -O3 $(PTHREAD_LIB) -o $@ $< ,"LINK","$(TARGET_DIR)$@")
+ $(call quiet-command, $(CC) -static -O3 $(PTHREAD_LIB) -o $@ $< ,"LINK","$(TARGET_DIR)$@")
INITRD_WORK_DIR=tests/migration/initrd
--
2.7.4
On 2 October 2017 at 09:30, Alexey Perevalov <a.perevalov@samsung.com> wrote: > This patch just replaces LINKPROG for CC. > LINKPROG invokes both CXX and CC. > So in case of static linking of C source, static libstdc++ > is required by build, but it could be missing in system. > And static libstdc++ may not be needed for whole QEMU. > > Signed-off-by: Alexey Perevalov <a.perevalov@samsung.com> > --- > tests/Makefile.include | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/Makefile.include b/tests/Makefile.include > index abc6707..bf94516 100644 > --- a/tests/Makefile.include > +++ b/tests/Makefile.include > @@ -803,7 +803,7 @@ tests/numa-test$(EXESUF): tests/numa-test.o > tests/vmgenid-test$(EXESUF): tests/vmgenid-test.o tests/boot-sector.o tests/acpi-utils.o > > tests/migration/stress$(EXESUF): tests/migration/stress.o > - $(call quiet-command, $(LINKPROG) -static -O3 $(PTHREAD_LIB) -o $@ $< ,"LINK","$(TARGET_DIR)$@") > + $(call quiet-command, $(CC) -static -O3 $(PTHREAD_LIB) -o $@ $< ,"LINK","$(TARGET_DIR)$@") > > INITRD_WORK_DIR=tests/migration/initrd Why does this executable need to define its own link rule anyway? Ideally it should just use the standard rules.mak LINK function like everything else. If it does need to do something weird it should have a comment saying why it's weird... thanks -- PMM
On Mon, Oct 02, 2017 at 12:14:39PM +0100, Peter Maydell wrote: > On 2 October 2017 at 09:30, Alexey Perevalov <a.perevalov@samsung.com> wrote: > > This patch just replaces LINKPROG for CC. > > LINKPROG invokes both CXX and CC. > > So in case of static linking of C source, static libstdc++ > > is required by build, but it could be missing in system. > > And static libstdc++ may not be needed for whole QEMU. > > > > Signed-off-by: Alexey Perevalov <a.perevalov@samsung.com> > > --- > > tests/Makefile.include | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tests/Makefile.include b/tests/Makefile.include > > index abc6707..bf94516 100644 > > --- a/tests/Makefile.include > > +++ b/tests/Makefile.include > > @@ -803,7 +803,7 @@ tests/numa-test$(EXESUF): tests/numa-test.o > > tests/vmgenid-test$(EXESUF): tests/vmgenid-test.o tests/boot-sector.o tests/acpi-utils.o > > > > tests/migration/stress$(EXESUF): tests/migration/stress.o > > - $(call quiet-command, $(LINKPROG) -static -O3 $(PTHREAD_LIB) -o $@ $< ,"LINK","$(TARGET_DIR)$@") > > + $(call quiet-command, $(CC) -static -O3 $(PTHREAD_LIB) -o $@ $< ,"LINK","$(TARGET_DIR)$@") > > > > INITRD_WORK_DIR=tests/migration/initrd > > Why does this executable need to define its own link rule anyway? > Ideally it should just use the standard rules.mak LINK function > like everything else. If it does need to do something weird > it should have a comment saying why it's weird... Primarily because we're static linking this binary so that it can be put into an initrd without needing any extra files added. It doesn't use any of the 3rd party libraries the rest of QEMU uses - ie no glib2 in particular. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 2 October 2017 at 12:17, Daniel P. Berrange <berrange@redhat.com> wrote: > On Mon, Oct 02, 2017 at 12:14:39PM +0100, Peter Maydell wrote: >> Why does this executable need to define its own link rule anyway? >> Ideally it should just use the standard rules.mak LINK function >> like everything else. If it does need to do something weird >> it should have a comment saying why it's weird... > > Primarily because we're static linking this binary so that it can be put > into an initrd without needing any extra files added. It doesn't use any > of the 3rd party libraries the rest of QEMU uses - ie no glib2 in particular. Oh, are we committing our usual error of trying to build guest binaries with the host toolchain? thanks -- PMM
On Mon, Oct 02, 2017 at 12:19:54PM +0100, Peter Maydell wrote: > On 2 October 2017 at 12:17, Daniel P. Berrange <berrange@redhat.com> wrote: > > On Mon, Oct 02, 2017 at 12:14:39PM +0100, Peter Maydell wrote: > >> Why does this executable need to define its own link rule anyway? > >> Ideally it should just use the standard rules.mak LINK function > >> like everything else. If it does need to do something weird > >> it should have a comment saying why it's weird... > > > > Primarily because we're static linking this binary so that it can be put > > into an initrd without needing any extra files added. It doesn't use any > > of the 3rd party libraries the rest of QEMU uses - ie no glib2 in particular. > > Oh, are we committing our usual error of trying to build guest > binaries with the host toolchain? That's not an error here - this test suite is only intended to run with matching host/guest arch, and boots with the host kernel + custom initrd containing only this binary. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
© 2016 - 2024 Red Hat, Inc.