All of lore.kernel.org
 help / color / mirror / Atom feed
* [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
* [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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.