* [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL @ 2021-02-09 10:47 Veronika Kremneva 2021-02-10 21:45 ` Yann E. MORIN 2021-05-15 15:12 ` Yann E. MORIN 0 siblings, 2 replies; 8+ messages in thread From: Veronika Kremneva @ 2021-02-09 10:47 UTC (permalink / raw) To: buildroot When building dmalloc for ARC while having "-fstack-protector-all" option on, we are getting the following error: ------------------------------->8--------------------------- >>> dmalloc 5.5.2 Installing to target cp -dpf $HOME/buildroot/output/host/arc-buildroot-linux-gnu/sysroot/usr/lib/libdmalloc*.so $HOME/buildroot/output/target/usr/lib cp -dpf $HOME/buildroot/output/host/arc-buildroot-linux-gnu/sysroot/usr/bin/dmalloc $HOME/buildroot/output/target/usr/bin/dmalloc ERROR: architecture for "/usr/lib/libdmallocthcxx.so" is "ARCompact", should be "ARCv2" ERROR: architecture for "/usr/lib/libdmallocth.so" is "ARCompact", should be "ARCv2" ERROR: architecture for "/usr/lib/libdmalloc.so" is "ARCompact", should be "ARCv2" ERROR: architecture for "/usr/lib/libdmallocxx.so" is "ARCompact", should be "ARCv2" make: *** [$HOME/buildroot/output/build/dmalloc-5.5.2/.stamp_installed] Error 1 ------------------------------->8--------------------------- You can observe this error in following builds: http://autobuild.buildroot.net/results/57f/57fc51cee4ec9339ea3be23f8c8c9f7ecca1a857/ http://autobuild.buildroot.net/results/b4d/b4d457369f35e1942c294b0ea3b3cab4cae0d7a3/ http://autobuild.buildroot.net/results/cfc/cfc111076c955dd5c1125c6e34a161121ea11200/ http://autobuild.buildroot.net/results/1d0/1d0ffcefbf545d1748e928603fd07c0a8de98eb5/ In all of those builds architecture "ARCv2" was explicitly chosen during configuration yet we are getting this error. As we go deeper we find that the object file that linker is trying to process contains no target code thus the default "ARCompact" is being used. But why the object file is empty? Went to check link args: ------------------------------->8--------------------------- $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: conftest.a(conftest.o): relocation R_ARC_32_ME against `__stack_chk_guard' can not be used when making a shared object; recompile with -fPIC $HOME/buildrootc/output/host/bin/arc-buildroot-linux-gnu-ld: BFD (GNU Binutils) 2.34.50.20200611 assertion fail elf32-arc.c:1802 $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: unrecognized option '-all' $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: use the --help option for usage information configure:4475: result: $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld -G -o $@.t ------------------------------->8--------------------------- Looks like we are missing the -fPIC flag in DMALLOC_CFLAGS. As shared libraries should always be compiled with "-fPIC" following patch adds this flag to the dmalloc.mk. Signed-off-by: Veronika Kremneva <kremneva@synopsys.com> --- package/dmalloc/dmalloc.mk | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/package/dmalloc/dmalloc.mk b/package/dmalloc/dmalloc.mk index 38b2c02027..638fe0fcda 100644 --- a/package/dmalloc/dmalloc.mk +++ b/package/dmalloc/dmalloc.mk @@ -16,6 +16,10 @@ DMALLOC_INSTALL_STAGING = YES DMALLOC_CONF_OPTS = --enable-shlib DMALLOC_CFLAGS = $(TARGET_CFLAGS) +ifeq ($(BR2_STATIC_LIBS),) +DMALLOC_CFLAGS += -fPIC +endif + ifeq ($(BR2_INSTALL_LIBSTDCPP),y) DMALLOC_CONF_OPTS += --enable-cxx else -- 2.16.2 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL 2021-02-09 10:47 [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL Veronika Kremneva @ 2021-02-10 21:45 ` Yann E. MORIN 2021-02-12 20:19 ` Fabrice Fontaine 2021-05-15 15:12 ` Yann E. MORIN 1 sibling, 1 reply; 8+ messages in thread From: Yann E. MORIN @ 2021-02-10 21:45 UTC (permalink / raw) To: buildroot Veronika, All, +Fabrice, see below... On 2021-02-09 13:47 +0300, Veronika Kremneva spake thusly: > When building dmalloc for ARC while having "-fstack-protector-all" option on, > we are getting the following error: > ------------------------------->8--------------------------- > >>> dmalloc 5.5.2 Installing to target > cp -dpf $HOME/buildroot/output/host/arc-buildroot-linux-gnu/sysroot/usr/lib/libdmalloc*.so > $HOME/buildroot/output/target/usr/lib > cp -dpf $HOME/buildroot/output/host/arc-buildroot-linux-gnu/sysroot/usr/bin/dmalloc > $HOME/buildroot/output/target/usr/bin/dmalloc > ERROR: architecture for "/usr/lib/libdmallocthcxx.so" is "ARCompact", should be "ARCv2" > ERROR: architecture for "/usr/lib/libdmallocth.so" is "ARCompact", should be "ARCv2" > ERROR: architecture for "/usr/lib/libdmalloc.so" is "ARCompact", should be "ARCv2" > ERROR: architecture for "/usr/lib/libdmallocxx.so" is "ARCompact", should be "ARCv2" > make: *** [$HOME/buildroot/output/build/dmalloc-5.5.2/.stamp_installed] Error 1 > ------------------------------->8--------------------------- > > You can observe this error in following builds: > http://autobuild.buildroot.net/results/57f/57fc51cee4ec9339ea3be23f8c8c9f7ecca1a857/ > http://autobuild.buildroot.net/results/b4d/b4d457369f35e1942c294b0ea3b3cab4cae0d7a3/ > http://autobuild.buildroot.net/results/cfc/cfc111076c955dd5c1125c6e34a161121ea11200/ > http://autobuild.buildroot.net/results/1d0/1d0ffcefbf545d1748e928603fd07c0a8de98eb5/ > > In all of those builds architecture "ARCv2" was explicitly chosen during configuration > yet we are getting this error. As we go deeper we find that the object file that linker > is trying to process contains no target code thus the default "ARCompact" is being used. > But why the object file is empty? Went to check link args: > ------------------------------->8--------------------------- > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: conftest.a(conftest.o): > relocation R_ARC_32_ME against `__stack_chk_guard' can not be used when making a shared > object; recompile with -fPIC > $HOME/buildrootc/output/host/bin/arc-buildroot-linux-gnu-ld: BFD (GNU Binutils) 2.34.50.20200611 > assertion fail elf32-arc.c:1802 > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: unrecognized option '-all' > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: use the --help option for usage information > configure:4475: result: $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld -G -o $@.t > ------------------------------->8--------------------------- > > Looks like we are missing the -fPIC flag in DMALLOC_CFLAGS. As shared libraries should always > be compiled with "-fPIC" following patch adds this flag to the dmalloc.mk. While reviewing that patch, I see that Fabrice already sent a similar patch quite some time ago now: https://patchwork.ozlabs.org/project/buildroot/patch/20200601092104.830051-1-fontaine.fabrice at gmail.com/ > Signed-off-by: Veronika Kremneva <kremneva@synopsys.com> > --- > package/dmalloc/dmalloc.mk | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/package/dmalloc/dmalloc.mk b/package/dmalloc/dmalloc.mk > index 38b2c02027..638fe0fcda 100644 > --- a/package/dmalloc/dmalloc.mk > +++ b/package/dmalloc/dmalloc.mk > @@ -16,6 +16,10 @@ DMALLOC_INSTALL_STAGING = YES > DMALLOC_CONF_OPTS = --enable-shlib > DMALLOC_CFLAGS = $(TARGET_CFLAGS) > > +ifeq ($(BR2_STATIC_LIBS),) > +DMALLOC_CFLAGS += -fPIC So, it seems that both of you arrived to a similar conclusion, with a similar analysis. I think the change from Fabrice would in the end be better, if it at least because it drops a bundled patch. Except for that, I wonder if we care about not adding -fPIC for static libs. Indeed, the current patch unconditionally adds -fPIC to all builds, shared and static alike... Besides, -fPIC is almost innocuous for static builds (maybe a very slight overhead to resolve or jump to some symbols)... What's your thoughts, both Veronika and Fabrice? Regards, Yann E. MORIN. > +endif > + > ifeq ($(BR2_INSTALL_LIBSTDCPP),y) > DMALLOC_CONF_OPTS += --enable-cxx > else > -- > 2.16.2 > > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL 2021-02-10 21:45 ` Yann E. MORIN @ 2021-02-12 20:19 ` Fabrice Fontaine 2021-02-13 8:27 ` Alexey Brodkin 0 siblings, 1 reply; 8+ messages in thread From: Fabrice Fontaine @ 2021-02-12 20:19 UTC (permalink / raw) To: buildroot Hi Yann, Le mer. 10 f?vr. 2021 ? 22:45, Yann E. MORIN <yann.morin.1998@free.fr> a ?crit : > > Veronika, All, > > +Fabrice, see below... > > On 2021-02-09 13:47 +0300, Veronika Kremneva spake thusly: > > When building dmalloc for ARC while having "-fstack-protector-all" option on, > > we are getting the following error: > > ------------------------------->8--------------------------- > > >>> dmalloc 5.5.2 Installing to target > > cp -dpf $HOME/buildroot/output/host/arc-buildroot-linux-gnu/sysroot/usr/lib/libdmalloc*.so > > $HOME/buildroot/output/target/usr/lib > > cp -dpf $HOME/buildroot/output/host/arc-buildroot-linux-gnu/sysroot/usr/bin/dmalloc > > $HOME/buildroot/output/target/usr/bin/dmalloc > > ERROR: architecture for "/usr/lib/libdmallocthcxx.so" is "ARCompact", should be "ARCv2" > > ERROR: architecture for "/usr/lib/libdmallocth.so" is "ARCompact", should be "ARCv2" > > ERROR: architecture for "/usr/lib/libdmalloc.so" is "ARCompact", should be "ARCv2" > > ERROR: architecture for "/usr/lib/libdmallocxx.so" is "ARCompact", should be "ARCv2" > > make: *** [$HOME/buildroot/output/build/dmalloc-5.5.2/.stamp_installed] Error 1 > > ------------------------------->8--------------------------- > > > > You can observe this error in following builds: > > http://autobuild.buildroot.net/results/57f/57fc51cee4ec9339ea3be23f8c8c9f7ecca1a857/ > > http://autobuild.buildroot.net/results/b4d/b4d457369f35e1942c294b0ea3b3cab4cae0d7a3/ > > http://autobuild.buildroot.net/results/cfc/cfc111076c955dd5c1125c6e34a161121ea11200/ > > http://autobuild.buildroot.net/results/1d0/1d0ffcefbf545d1748e928603fd07c0a8de98eb5/ > > > > In all of those builds architecture "ARCv2" was explicitly chosen during configuration > > yet we are getting this error. As we go deeper we find that the object file that linker > > is trying to process contains no target code thus the default "ARCompact" is being used. > > But why the object file is empty? Went to check link args: > > ------------------------------->8--------------------------- > > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: conftest.a(conftest.o): > > relocation R_ARC_32_ME against `__stack_chk_guard' can not be used when making a shared > > object; recompile with -fPIC > > $HOME/buildrootc/output/host/bin/arc-buildroot-linux-gnu-ld: BFD (GNU Binutils) 2.34.50.20200611 > > assertion fail elf32-arc.c:1802 > > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: unrecognized option '-all' > > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: use the --help option for usage information > > configure:4475: result: $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld -G -o $@.t > > ------------------------------->8--------------------------- > > > > Looks like we are missing the -fPIC flag in DMALLOC_CFLAGS. As shared libraries should always > > be compiled with "-fPIC" following patch adds this flag to the dmalloc.mk. > > While reviewing that patch, I see that Fabrice already sent a similar > patch quite some time ago now: > > https://patchwork.ozlabs.org/project/buildroot/patch/20200601092104.830051-1-fontaine.fabrice at gmail.com/ > > > Signed-off-by: Veronika Kremneva <kremneva@synopsys.com> > > --- > > package/dmalloc/dmalloc.mk | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/package/dmalloc/dmalloc.mk b/package/dmalloc/dmalloc.mk > > index 38b2c02027..638fe0fcda 100644 > > --- a/package/dmalloc/dmalloc.mk > > +++ b/package/dmalloc/dmalloc.mk > > @@ -16,6 +16,10 @@ DMALLOC_INSTALL_STAGING = YES > > DMALLOC_CONF_OPTS = --enable-shlib > > DMALLOC_CFLAGS = $(TARGET_CFLAGS) > > > > +ifeq ($(BR2_STATIC_LIBS),) > > +DMALLOC_CFLAGS += -fPIC > > So, it seems that both of you arrived to a similar conclusion, with a > similar analysis. > > I think the change from Fabrice would in the end be better, if it at > least because it drops a bundled patch. > > Except for that, I wonder if we care about not adding -fPIC for static > libs. Indeed, the current patch unconditionally adds -fPIC to all > builds, shared and static alike... > > Besides, -fPIC is almost innocuous for static builds (maybe a very > slight overhead to resolve or jump to some symbols)... > > What's your thoughts, both Veronika and Fabrice? It seems that we're not always consistent with -fPIC handling: - most of the packages only set -fPIC if BR2_STATIC_LIBS is not set - but some packages (e.g. argp-standalone, ficl, jimtcl, lbase64 ...) set it unconditionally So I have no strong opinion on both options. > > Regards, > Yann E. MORIN. > > > +endif > > + > > ifeq ($(BR2_INSTALL_LIBSTDCPP),y) > > DMALLOC_CONF_OPTS += --enable-cxx > > else > > -- > > 2.16.2 > > > > _______________________________________________ > > buildroot mailing list > > buildroot at busybox.net > > http://lists.busybox.net/mailman/listinfo/buildroot > > -- > .-----------------.--------------------.------------------.--------------------. > | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | > | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | > | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | > '------------------------------^-------^------------------^--------------------' Best Regards, Fabrice ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL 2021-02-12 20:19 ` Fabrice Fontaine @ 2021-02-13 8:27 ` Alexey Brodkin [not found] ` <SN1PR12MB2351CE14450D2AF4FA2C36B5CA9D9@SN1PR12MB2351.namprd12.prod.outlook.com> 0 siblings, 1 reply; 8+ messages in thread From: Alexey Brodkin @ 2021-02-13 8:27 UTC (permalink / raw) To: buildroot Hi Yann, Fabrice, Veronika, all, > > > > Veronika, All, > > > > +Fabrice, see below... > > > > On 2021-02-09 13:47 +0300, Veronika Kremneva spake thusly: > > > When building dmalloc for ARC while having "-fstack-protector-all" option on, > > > we are getting the following error: > > > ------------------------------->8--------------------------- > > > >>> dmalloc 5.5.2 Installing to target > > > cp -dpf $HOME/buildroot/output/host/arc-buildroot-linux-gnu/sysroot/usr/lib/libdmalloc*.so > > > $HOME/buildroot/output/target/usr/lib > > > cp -dpf $HOME/buildroot/output/host/arc-buildroot-linux-gnu/sysroot/usr/bin/dmalloc > > > $HOME/buildroot/output/target/usr/bin/dmalloc > > > ERROR: architecture for "/usr/lib/libdmallocthcxx.so" is "ARCompact", should be "ARCv2" > > > ERROR: architecture for "/usr/lib/libdmallocth.so" is "ARCompact", should be "ARCv2" > > > ERROR: architecture for "/usr/lib/libdmalloc.so" is "ARCompact", should be "ARCv2" > > > ERROR: architecture for "/usr/lib/libdmallocxx.so" is "ARCompact", should be "ARCv2" > > > make: *** [$HOME/buildroot/output/build/dmalloc-5.5.2/.stamp_installed] Error 1 > > > ------------------------------->8--------------------------- > > > > > > You can observe this error in following builds: > > > https://urldefense.com/v3/__http://autobuild.buildroot.net/results/57f/57fc51cee4ec9339ea3be23f8c8c9f7ecca1a857/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0DCT50oA$ > > > https://urldefense.com/v3/__http://autobuild.buildroot.net/results/b4d/b4d457369f35e1942c294b0ea3b3cab4cae0d7a3/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0TIQeXfo$ > > > https://urldefense.com/v3/__http://autobuild.buildroot.net/results/cfc/cfc111076c955dd5c1125c6e34a161121ea11200/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0Zou_QLI$ > > > https://urldefense.com/v3/__http://autobuild.buildroot.net/results/1d0/1d0ffcefbf545d1748e928603fd07c0a8de98eb5/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0sWpt_q8$ > > > > > > In all of those builds architecture "ARCv2" was explicitly chosen during configuration > > > yet we are getting this error. As we go deeper we find that the object file that linker > > > is trying to process contains no target code thus the default "ARCompact" is being used. > > > But why the object file is empty? Went to check link args: > > > ------------------------------->8--------------------------- > > > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: conftest.a(conftest.o): > > > relocation R_ARC_32_ME against `__stack_chk_guard' can not be used when making a shared > > > object; recompile with -fPIC > > > $HOME/buildrootc/output/host/bin/arc-buildroot-linux-gnu-ld: BFD (GNU Binutils) 2.34.50.20200611 > > > assertion fail elf32-arc.c:1802 > > > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: unrecognized option '-all' > > > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: use the --help option for usage information > > > configure:4475: result: $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld -G -o $@.t > > > ------------------------------->8--------------------------- > > > > > > Looks like we are missing the -fPIC flag in DMALLOC_CFLAGS. As shared libraries should always > > > be compiled with "-fPIC" following patch adds this flag to the dmalloc.mk. > > > > While reviewing that patch, I see that Fabrice already sent a similar > > patch quite some time ago now: > > > > https://urldefense.com/v3/__https://patchwork.ozlabs.org/project/buildroot/patch/20200601092104.830051-1-fontaine.fabrice at gmail.com/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0HTmC8VI$ > > > > > Signed-off-by: Veronika Kremneva <kremneva@synopsys.com> > > > --- > > > package/dmalloc/dmalloc.mk | 4 ++++ > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/package/dmalloc/dmalloc.mk b/package/dmalloc/dmalloc.mk > > > index 38b2c02027..638fe0fcda 100644 > > > --- a/package/dmalloc/dmalloc.mk > > > +++ b/package/dmalloc/dmalloc.mk > > > @@ -16,6 +16,10 @@ DMALLOC_INSTALL_STAGING = YES > > > DMALLOC_CONF_OPTS = --enable-shlib > > > DMALLOC_CFLAGS = $(TARGET_CFLAGS) > > > > > > +ifeq ($(BR2_STATIC_LIBS),) > > > +DMALLOC_CFLAGS += -fPIC > > > > So, it seems that both of you arrived to a similar conclusion, with a > > similar analysis. > > > > I think the change from Fabrice would in the end be better, if it at > > least because it drops a bundled patch. > > > > Except for that, I wonder if we care about not adding -fPIC for static > > libs. Indeed, the current patch unconditionally adds -fPIC to all > > builds, shared and static alike... > > > > Besides, -fPIC is almost innocuous for static builds (maybe a very > > slight overhead to resolve or jump to some symbols)... > > > > What's your thoughts, both Veronika and Fabrice? > It seems that we're not always consistent with -fPIC handling: > - most of the packages only set -fPIC if BR2_STATIC_LIBS is not set > - but some packages (e.g. argp-standalone, ficl, jimtcl, lbase64 ...) > set it unconditionally > So I have no strong opinion on both options. Since I'm not a compiler person I don't have any strong opinion here, except maybe for some common sense idea of not using option typically used for shared libs (-fPIC) for statically linked stuff. Thus it would be good to hear our GCC expert how appropriate and/or safe is could be to compile object files with "-fPIC" if we're going to build a statically-linked application? Claudiu, could you please chime in and share your thoughts in general and if applied to ARC in particular. -Alexey ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <SN1PR12MB2351CE14450D2AF4FA2C36B5CA9D9@SN1PR12MB2351.namprd12.prod.outlook.com>]
* [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL [not found] ` <SN1PR12MB2351CE14450D2AF4FA2C36B5CA9D9@SN1PR12MB2351.namprd12.prod.outlook.com> @ 2021-03-03 12:22 ` Alexey Brodkin 2021-04-16 12:13 ` Veronika Kremneva 1 sibling, 0 replies; 8+ messages in thread From: Alexey Brodkin @ 2021-03-03 12:22 UTC (permalink / raw) To: buildroot Hi Yann, all, I guess we may settle on building Dmalloc with "-fPIC" unconditionally. Is there anything else we may do here? Re-spin of anything etc? -Alexey ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL [not found] ` <SN1PR12MB2351CE14450D2AF4FA2C36B5CA9D9@SN1PR12MB2351.namprd12.prod.outlook.com> 2021-03-03 12:22 ` Alexey Brodkin @ 2021-04-16 12:13 ` Veronika Kremneva 2021-04-16 12:42 ` Fabrice Fontaine 1 sibling, 1 reply; 8+ messages in thread From: Veronika Kremneva @ 2021-04-16 12:13 UTC (permalink / raw) To: buildroot Hi Fabrice, This problem still persists: http://autobuild.buildroot.net/?reason=dmalloc-5.5.2 Do you have any interest in proceeding with your patch<https://patchwork.ozlabs.org/project/buildroot/patch/20200601092104.830051-1-fontaine.fabrice@gmail.com/> fixing it or should I go with my patch instead? Best regards, Veronika From: Claudiu Zissulescu <claziss@synopsys.com> Sent: Friday, February 26, 2021 12:51 PM To: Alexey Brodkin <abrodkin@synopsys.com>; Fabrice Fontaine <fontaine.fabrice@gmail.com>; Yann E. MORIN <yann.morin.1998@free.fr> Cc: Veronika Kremneva <kremneva@synopsys.com>; Fabrice Fontaine via buildroot <buildroot@busybox.net>; Evgeniy Didin <didin@synopsys.com>; ARC Buildroot mailing list <arc-buildroot@synopsys.com> Subject: Re: [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL Hi, You can use -fpic with any static object, the linker will resolve all the symbols at compile-time. However, the resulted code may be less performant (code size/speed) than without fpic option. Cheers, Claudiu ________________________________ From: Alexey Brodkin <abrodkin at synopsys.com<mailto:abrodkin@synopsys.com>> Sent: Saturday, February 13, 2021 10:27 AM To: Fabrice Fontaine <fontaine.fabrice at gmail.com<mailto:fontaine.fabrice@gmail.com>>; Yann E. MORIN <yann.morin.1998 at free.fr<mailto:yann.morin.1998@free.fr>>; Claudiu Zissulescu <claziss at synopsys.com<mailto:claziss@synopsys.com>> Cc: Veronika Kremneva <kremneva at synopsys.com<mailto:kremneva@synopsys.com>>; Fabrice Fontaine via buildroot <buildroot at busybox.net<mailto:buildroot@busybox.net>>; Evgeniy Didin <didin at synopsys.com<mailto:didin@synopsys.com>>; Claudiu Zissulescu <claziss at synopsys.com<mailto:claziss@synopsys.com>>; ARC Buildroot mailing list <arc-buildroot at synopsys.com<mailto:arc-buildroot@synopsys.com>> Subject: Re: [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL Hi Yann, Fabrice, Veronika, all, > > > > Veronika, All, > > > > +Fabrice, see below... > > > > On 2021-02-09 13:47 +0300, Veronika Kremneva spake thusly: > > > When building dmalloc for ARC while having "-fstack-protector-all" option on, > > > we are getting the following error: > > > ------------------------------->8--------------------------- > > > >>> dmalloc 5.5.2 Installing to target > > > cp -dpf $HOME/buildroot/output/host/arc-buildroot-linux-gnu/sysroot/usr/lib/libdmalloc*.so > > > $HOME/buildroot/output/target/usr/lib > > > cp -dpf $HOME/buildroot/output/host/arc-buildroot-linux-gnu/sysroot/usr/bin/dmalloc > > > $HOME/buildroot/output/target/usr/bin/dmalloc > > > ERROR: architecture for "/usr/lib/libdmallocthcxx.so" is "ARCompact", should be "ARCv2" > > > ERROR: architecture for "/usr/lib/libdmallocth.so" is "ARCompact", should be "ARCv2" > > > ERROR: architecture for "/usr/lib/libdmalloc.so" is "ARCompact", should be "ARCv2" > > > ERROR: architecture for "/usr/lib/libdmallocxx.so" is "ARCompact", should be "ARCv2" > > > make: *** [$HOME/buildroot/output/build/dmalloc-5.5.2/.stamp_installed] Error 1 > > > ------------------------------->8--------------------------- > > > > > > You can observe this error in following builds: > > > https://urldefense.com/v3/__http://autobuild.buildroot.net/results/57f/57fc51cee4ec9339ea3be23f8c8c9f7ecca1a857/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0DCT50oA$<https://urldefense.com/v3/__http:/autobuild.buildroot.net/results/57f/57fc51cee4ec9339ea3be23f8c8c9f7ecca1a857/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0DCT50oA$> > > > https://urldefense.com/v3/__http://autobuild.buildroot.net/results/b4d/b4d457369f35e1942c294b0ea3b3cab4cae0d7a3/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0TIQeXfo$<https://urldefense.com/v3/__http:/autobuild.buildroot.net/results/b4d/b4d457369f35e1942c294b0ea3b3cab4cae0d7a3/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0TIQeXfo$> > > > https://urldefense.com/v3/__http://autobuild.buildroot.net/results/cfc/cfc111076c955dd5c1125c6e34a161121ea11200/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0Zou_QLI$<https://urldefense.com/v3/__http:/autobuild.buildroot.net/results/cfc/cfc111076c955dd5c1125c6e34a161121ea11200/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0Zou_QLI$> > > > https://urldefense.com/v3/__http://autobuild.buildroot.net/results/1d0/1d0ffcefbf545d1748e928603fd07c0a8de98eb5/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0sWpt_q8$<https://urldefense.com/v3/__http:/autobuild.buildroot.net/results/1d0/1d0ffcefbf545d1748e928603fd07c0a8de98eb5/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0sWpt_q8$> > > > > > > In all of those builds architecture "ARCv2" was explicitly chosen during configuration > > > yet we are getting this error. As we go deeper we find that the object file that linker > > > is trying to process contains no target code thus the default "ARCompact" is being used. > > > But why the object file is empty? Went to check link args: > > > ------------------------------->8--------------------------- > > > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: conftest.a(conftest.o): > > > relocation R_ARC_32_ME against `__stack_chk_guard' can not be used when making a shared > > > object; recompile with -fPIC > > > $HOME/buildrootc/output/host/bin/arc-buildroot-linux-gnu-ld: BFD (GNU Binutils) 2.34.50.20200611 > > > assertion fail elf32-arc.c:1802 > > > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: unrecognized option '-all' > > > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: use the --help option for usage information > > > configure:4475: result: $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld -G -o $@.t<mailto:$@.t> > > > ------------------------------->8--------------------------- > > > > > > Looks like we are missing the -fPIC flag in DMALLOC_CFLAGS. As shared libraries should always > > > be compiled with "-fPIC" following patch adds this flag to the dmalloc.mk. > > > > While reviewing that patch, I see that Fabrice already sent a similar > > patch quite some time ago now: > > > > https://urldefense.com/v3/__https://patchwork.ozlabs.org/project/buildroot/patch/20200601092104.830051-1-fontaine.fabrice at gmail.com/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0HTmC8VI$<https://urldefense.com/v3/__https:/patchwork.ozlabs.org/project/buildroot/patch/20200601092104.830051-1-fontaine.fabrice@gmail.com/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0HTmC8VI$> > > > > > Signed-off-by: Veronika Kremneva <kremneva at synopsys.com<mailto:kremneva@synopsys.com>> > > > --- > > > package/dmalloc/dmalloc.mk | 4 ++++ > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/package/dmalloc/dmalloc.mk b/package/dmalloc/dmalloc.mk > > > index 38b2c02027..638fe0fcda 100644 > > > --- a/package/dmalloc/dmalloc.mk > > > +++ b/package/dmalloc/dmalloc.mk > > > @@ -16,6 +16,10 @@ DMALLOC_INSTALL_STAGING = YES > > > DMALLOC_CONF_OPTS = --enable-shlib > > > DMALLOC_CFLAGS = $(TARGET_CFLAGS) > > > > > > +ifeq ($(BR2_STATIC_LIBS),) > > > +DMALLOC_CFLAGS += -fPIC > > > > So, it seems that both of you arrived to a similar conclusion, with a > > similar analysis. > > > > I think the change from Fabrice would in the end be better, if it at > > least because it drops a bundled patch. > > > > Except for that, I wonder if we care about not adding -fPIC for static > > libs. Indeed, the current patch unconditionally adds -fPIC to all > > builds, shared and static alike... > > > > Besides, -fPIC is almost innocuous for static builds (maybe a very > > slight overhead to resolve or jump to some symbols)... > > > > What's your thoughts, both Veronika and Fabrice? > It seems that we're not always consistent with -fPIC handling: > - most of the packages only set -fPIC if BR2_STATIC_LIBS is not set > - but some packages (e.g. argp-standalone, ficl, jimtcl, lbase64 ...) > set it unconditionally > So I have no strong opinion on both options. Since I'm not a compiler person I don't have any strong opinion here, except maybe for some common sense idea of not using option typically used for shared libs (-fPIC) for statically linked stuff. Thus it would be good to hear our GCC expert how appropriate and/or safe is could be to compile object files with "-fPIC" if we're going to build a statically-linked application? Claudiu, could you please chime in and share your thoughts in general and if applied to ARC in particular. -Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20210416/2502b7f8/attachment.html> ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL 2021-04-16 12:13 ` Veronika Kremneva @ 2021-04-16 12:42 ` Fabrice Fontaine 0 siblings, 0 replies; 8+ messages in thread From: Fabrice Fontaine @ 2021-04-16 12:42 UTC (permalink / raw) To: buildroot Hi Veronika, I think we should merge both patches: - setting -fPIC conditionally - dropping first patch If you have time to update your patch, please feel free to do so. Otherwise, I'll update mine this week-end. Best Regards, Fabrice Le ven. 16 avr. 2021 ? 14:13, Veronika Kremneva <Veronika.Kremneva@synopsys.com> a ?crit : > > Hi Fabrice, > > > > This problem still persists: > http://autobuild.buildroot.net/?reason=dmalloc-5.5.2 > > Do you have any interest in proceeding with your patch fixing it or should I go with my patch instead? > > > > Best regards, > > Veronika > > > > From: Claudiu Zissulescu <claziss@synopsys.com> > Sent: Friday, February 26, 2021 12:51 PM > To: Alexey Brodkin <abrodkin@synopsys.com>; Fabrice Fontaine <fontaine.fabrice@gmail.com>; Yann E. MORIN <yann.morin.1998@free.fr> > Cc: Veronika Kremneva <kremneva@synopsys.com>; Fabrice Fontaine via buildroot <buildroot@busybox.net>; Evgeniy Didin <didin@synopsys.com>; ARC Buildroot mailing list <arc-buildroot@synopsys.com> > Subject: Re: [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL > > > > Hi, > > > > You can use -fpic with any static object, the linker will resolve all the symbols at compile-time. However, the resulted code may be less performant (code size/speed) than without fpic option. > > > > Cheers, > Claudiu > > ________________________________ > > From: Alexey Brodkin <abrodkin@synopsys.com> > Sent: Saturday, February 13, 2021 10:27 AM > To: Fabrice Fontaine <fontaine.fabrice@gmail.com>; Yann E. MORIN <yann.morin.1998@free.fr>; Claudiu Zissulescu <claziss@synopsys.com> > Cc: Veronika Kremneva <kremneva@synopsys.com>; Fabrice Fontaine via buildroot <buildroot@busybox.net>; Evgeniy Didin <didin@synopsys.com>; Claudiu Zissulescu <claziss@synopsys.com>; ARC Buildroot mailing list <arc-buildroot@synopsys.com> > Subject: Re: [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL > > > > Hi Yann, Fabrice, Veronika, all, > > > > > > > Veronika, All, > > > > > > +Fabrice, see below... > > > > > > On 2021-02-09 13:47 +0300, Veronika Kremneva spake thusly: > > > > When building dmalloc for ARC while having "-fstack-protector-all" option on, > > > > we are getting the following error: > > > > ------------------------------->8--------------------------- > > > > >>> dmalloc 5.5.2 Installing to target > > > > cp -dpf $HOME/buildroot/output/host/arc-buildroot-linux-gnu/sysroot/usr/lib/libdmalloc*.so > > > > $HOME/buildroot/output/target/usr/lib > > > > cp -dpf $HOME/buildroot/output/host/arc-buildroot-linux-gnu/sysroot/usr/bin/dmalloc > > > > $HOME/buildroot/output/target/usr/bin/dmalloc > > > > ERROR: architecture for "/usr/lib/libdmallocthcxx.so" is "ARCompact", should be "ARCv2" > > > > ERROR: architecture for "/usr/lib/libdmallocth.so" is "ARCompact", should be "ARCv2" > > > > ERROR: architecture for "/usr/lib/libdmalloc.so" is "ARCompact", should be "ARCv2" > > > > ERROR: architecture for "/usr/lib/libdmallocxx.so" is "ARCompact", should be "ARCv2" > > > > make: *** [$HOME/buildroot/output/build/dmalloc-5.5.2/.stamp_installed] Error 1 > > > > ------------------------------->8--------------------------- > > > > > > > > You can observe this error in following builds: > > > > https://urldefense.com/v3/__http://autobuild.buildroot.net/results/57f/57fc51cee4ec9339ea3be23f8c8c9f7ecca1a857/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0DCT50oA$ > > > > https://urldefense.com/v3/__http://autobuild.buildroot.net/results/b4d/b4d457369f35e1942c294b0ea3b3cab4cae0d7a3/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0TIQeXfo$ > > > > https://urldefense.com/v3/__http://autobuild.buildroot.net/results/cfc/cfc111076c955dd5c1125c6e34a161121ea11200/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0Zou_QLI$ > > > > https://urldefense.com/v3/__http://autobuild.buildroot.net/results/1d0/1d0ffcefbf545d1748e928603fd07c0a8de98eb5/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0sWpt_q8$ > > > > > > > > In all of those builds architecture "ARCv2" was explicitly chosen during configuration > > > > yet we are getting this error. As we go deeper we find that the object file that linker > > > > is trying to process contains no target code thus the default "ARCompact" is being used. > > > > But why the object file is empty? Went to check link args: > > > > ------------------------------->8--------------------------- > > > > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: conftest.a(conftest.o): > > > > relocation R_ARC_32_ME against `__stack_chk_guard' can not be used when making a shared > > > > object; recompile with -fPIC > > > > $HOME/buildrootc/output/host/bin/arc-buildroot-linux-gnu-ld: BFD (GNU Binutils) 2.34.50.20200611 > > > > assertion fail elf32-arc.c:1802 > > > > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: unrecognized option '-all' > > > > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: use the --help option for usage information > > > > configure:4475: result: $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld -G -o $@.t > > > > ------------------------------->8--------------------------- > > > > > > > > Looks like we are missing the -fPIC flag in DMALLOC_CFLAGS. As shared libraries should always > > > > be compiled with "-fPIC" following patch adds this flag to the dmalloc.mk. > > > > > > While reviewing that patch, I see that Fabrice already sent a similar > > > patch quite some time ago now: > > > > > > https://urldefense.com/v3/__https://patchwork.ozlabs.org/project/buildroot/patch/20200601092104.830051-1-fontaine.fabrice at gmail.com/__;!!A4F2R9G_pg!PHGtF8S30pSJyoPZQMVqH0kXGTbKzHEJjoQjJBl0QfYZsIsvjySA8l4aebUi2jb0HTmC8VI$ > > > > > > > Signed-off-by: Veronika Kremneva <kremneva@synopsys.com> > > > > --- > > > > package/dmalloc/dmalloc.mk | 4 ++++ > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/package/dmalloc/dmalloc.mk b/package/dmalloc/dmalloc.mk > > > > index 38b2c02027..638fe0fcda 100644 > > > > --- a/package/dmalloc/dmalloc.mk > > > > +++ b/package/dmalloc/dmalloc.mk > > > > @@ -16,6 +16,10 @@ DMALLOC_INSTALL_STAGING = YES > > > > DMALLOC_CONF_OPTS = --enable-shlib > > > > DMALLOC_CFLAGS = $(TARGET_CFLAGS) > > > > > > > > +ifeq ($(BR2_STATIC_LIBS),) > > > > +DMALLOC_CFLAGS += -fPIC > > > > > > So, it seems that both of you arrived to a similar conclusion, with a > > > similar analysis. > > > > > > I think the change from Fabrice would in the end be better, if it at > > > least because it drops a bundled patch. > > > > > > Except for that, I wonder if we care about not adding -fPIC for static > > > libs. Indeed, the current patch unconditionally adds -fPIC to all > > > builds, shared and static alike... > > > > > > Besides, -fPIC is almost innocuous for static builds (maybe a very > > > slight overhead to resolve or jump to some symbols)... > > > > > > What's your thoughts, both Veronika and Fabrice? > > It seems that we're not always consistent with -fPIC handling: > > - most of the packages only set -fPIC if BR2_STATIC_LIBS is not set > > - but some packages (e.g. argp-standalone, ficl, jimtcl, lbase64 ...) > > set it unconditionally > > So I have no strong opinion on both options. > > Since I'm not a compiler person I don't have any strong opinion here, > except maybe for some common sense idea of not using option typically used > for shared libs (-fPIC) for statically linked stuff. > > Thus it would be good to hear our GCC expert how appropriate and/or safe > is could be to compile object files with "-fPIC" if we're going to build > a statically-linked application? > > Claudiu, could you please chime in and share your thoughts in general and > if applied to ARC in particular. > > -Alexey ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL 2021-02-09 10:47 [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL Veronika Kremneva 2021-02-10 21:45 ` Yann E. MORIN @ 2021-05-15 15:12 ` Yann E. MORIN 1 sibling, 0 replies; 8+ messages in thread From: Yann E. MORIN @ 2021-05-15 15:12 UTC (permalink / raw) To: buildroot Veronica, All, On 2021-02-09 13:47 +0300, Veronika Kremneva spake thusly: > When building dmalloc for ARC while having "-fstack-protector-all" option on, > we are getting the following error: > ------------------------------->8--------------------------- > >>> dmalloc 5.5.2 Installing to target > cp -dpf $HOME/buildroot/output/host/arc-buildroot-linux-gnu/sysroot/usr/lib/libdmalloc*.so > $HOME/buildroot/output/target/usr/lib > cp -dpf $HOME/buildroot/output/host/arc-buildroot-linux-gnu/sysroot/usr/bin/dmalloc > $HOME/buildroot/output/target/usr/bin/dmalloc > ERROR: architecture for "/usr/lib/libdmallocthcxx.so" is "ARCompact", should be "ARCv2" > ERROR: architecture for "/usr/lib/libdmallocth.so" is "ARCompact", should be "ARCv2" > ERROR: architecture for "/usr/lib/libdmalloc.so" is "ARCompact", should be "ARCv2" > ERROR: architecture for "/usr/lib/libdmallocxx.so" is "ARCompact", should be "ARCv2" > make: *** [$HOME/buildroot/output/build/dmalloc-5.5.2/.stamp_installed] Error 1 > ------------------------------->8--------------------------- > > You can observe this error in following builds: > http://autobuild.buildroot.net/results/57f/57fc51cee4ec9339ea3be23f8c8c9f7ecca1a857/ > http://autobuild.buildroot.net/results/b4d/b4d457369f35e1942c294b0ea3b3cab4cae0d7a3/ > http://autobuild.buildroot.net/results/cfc/cfc111076c955dd5c1125c6e34a161121ea11200/ > http://autobuild.buildroot.net/results/1d0/1d0ffcefbf545d1748e928603fd07c0a8de98eb5/ > > In all of those builds architecture "ARCv2" was explicitly chosen during configuration > yet we are getting this error. As we go deeper we find that the object file that linker > is trying to process contains no target code thus the default "ARCompact" is being used. > But why the object file is empty? Went to check link args: > ------------------------------->8--------------------------- > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: conftest.a(conftest.o): > relocation R_ARC_32_ME against `__stack_chk_guard' can not be used when making a shared > object; recompile with -fPIC > $HOME/buildrootc/output/host/bin/arc-buildroot-linux-gnu-ld: BFD (GNU Binutils) 2.34.50.20200611 > assertion fail elf32-arc.c:1802 > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: unrecognized option '-all' > $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld: use the --help option for usage information > configure:4475: result: $HOME/buildroot/output/host/bin/arc-buildroot-linux-gnu-ld -G -o $@.t > ------------------------------->8--------------------------- > > Looks like we are missing the -fPIC flag in DMALLOC_CFLAGS. As shared libraries should always > be compiled with "-fPIC" following patch adds this flag to the dmalloc.mk. > > Signed-off-by: Veronika Kremneva <kremneva@synopsys.com> Following the bak-n0-forth in this thread, Fabrice eventually sent a patch that aggreagated his and yours, and that has been applied as commit 19ec872f169a (package/dmalloc: needs -fPIC) Thanks for your patch and the input in the discussion that followed! Regards, Yann E. MORIN. > --- > package/dmalloc/dmalloc.mk | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/package/dmalloc/dmalloc.mk b/package/dmalloc/dmalloc.mk > index 38b2c02027..638fe0fcda 100644 > --- a/package/dmalloc/dmalloc.mk > +++ b/package/dmalloc/dmalloc.mk > @@ -16,6 +16,10 @@ DMALLOC_INSTALL_STAGING = YES > DMALLOC_CONF_OPTS = --enable-shlib > DMALLOC_CFLAGS = $(TARGET_CFLAGS) > > +ifeq ($(BR2_STATIC_LIBS),) > +DMALLOC_CFLAGS += -fPIC > +endif > + > ifeq ($(BR2_INSTALL_LIBSTDCPP),y) > DMALLOC_CONF_OPTS += --enable-cxx > else > -- > 2.16.2 > > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-05-15 15:12 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-02-09 10:47 [Buildroot] [PATCH] package/dmalloc: Fix for ARC with enabled BR2_SSP_ALL Veronika Kremneva
2021-02-10 21:45 ` Yann E. MORIN
2021-02-12 20:19 ` Fabrice Fontaine
2021-02-13 8:27 ` Alexey Brodkin
[not found] ` <SN1PR12MB2351CE14450D2AF4FA2C36B5CA9D9@SN1PR12MB2351.namprd12.prod.outlook.com>
2021-03-03 12:22 ` Alexey Brodkin
2021-04-16 12:13 ` Veronika Kremneva
2021-04-16 12:42 ` Fabrice Fontaine
2021-05-15 15:12 ` Yann E. MORIN
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox