* [Buildroot] [PATCH v2] package/apcupsd: add -lstdc++ for ARC7* and SPARC
@ 2020-08-12 17:18 Evgeniy Didin
2020-08-17 7:25 ` Yann E. MORIN
0 siblings, 1 reply; 5+ messages in thread
From: Evgeniy Didin @ 2020-08-12 17:18 UTC (permalink / raw)
To: buildroot
For some reason apcupsd is not building for ARC700 and SPARC,
adding "-lstdc++" solves the issue.
Fixes:
http://autobuild.buildroot.org/results/3be/3bedf404de0ea42ee3ba624cded65d310a847af9//
http://autobuild.buildroot.org/results/6ab/6ab4e8021aad13bc153a6c22e87a77bf2bdc21e0//
Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot at synopsys.com
---
Changes since v1:
-Removed commented lines
package/apcupsd/apcupsd.mk | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/package/apcupsd/apcupsd.mk b/package/apcupsd/apcupsd.mk
index 410bce9aec..d2001419d6 100644
--- a/package/apcupsd/apcupsd.mk
+++ b/package/apcupsd/apcupsd.mk
@@ -18,6 +18,10 @@ APCUPSD_CONF_ENV += LIBS="`$(PKG_CONFIG_HOST_BINARY) --libs libusb`"
endif
endif
+ifeq ($(BR2_arc770d)$(BR2_arc750d)$(BR2_sparc),y)
+APCUPSD_CONF_ENV += LIBS+="-lstdc++"
+endif
+
ifeq ($(BR2_PACKAGE_APCUPSD_APCSMART),y)
APCUPSD_CONF_OPTS += --enable-apcsmart
else
--
2.16.2
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [Buildroot] [PATCH v2] package/apcupsd: add -lstdc++ for ARC7* and SPARC
2020-08-12 17:18 [Buildroot] [PATCH v2] package/apcupsd: add -lstdc++ for ARC7* and SPARC Evgeniy Didin
@ 2020-08-17 7:25 ` Yann E. MORIN
2020-08-17 7:51 ` James Hilliard
0 siblings, 1 reply; 5+ messages in thread
From: Yann E. MORIN @ 2020-08-17 7:25 UTC (permalink / raw)
To: buildroot
Evgeniy, James, All,
On 2020-08-12 20:18 +0300, Evgeniy Didin spake thusly:
> For some reason apcupsd is not building for ARC700 and SPARC,
> adding "-lstdc++" solves the issue.
So, as Thomas already replied, this is not an acceptable explanation.
The real question is "why are they forgetting to link with -lstdc++ when
linking a C++ program to begin with?"
And the reason is that they are using gcc to do the link line-wrapping
by me for readability):
$ make V=
/home/ymorin/dev/buildroot/O/host/bin/sparc-linux-gcc -static .obj/options.o \
.obj/device.o .obj/reports.o .obj/action.o .obj/apcupsd.o .obj/apcnis.o \
/home/ymorin/dev/buildroot/O/build/apcupsd-3.14.14/src/drivers/libdrivers.a \
/home/ymorin/dev/buildroot/O/build/apcupsd-3.14.14/src/drivers/apcsmart/libapcsmartdrv.a \
/home/ymorin/dev/buildroot/O/build/apcupsd-3.14.14/src/lib/libapc.a \
-o apcupsd -lsupc++ -lpthread
Why are they using 'sparc-linux-gcc'?
Buildroot passes LD='.../sparc-linux-ld' so it's not us passing an
inappropriate value.
So, investigating further, it turns out that in fact, apcusd is not
really an autotools package, since it only uses autoconf and not
automake, so their Makefiles are a not traditional... :-/
That aside, their autoconf/configure.in has this gem:
816 if test -n "$GCC"; then
817 # Starting with GCC 3.0, you must link C++ programs against either
818 # libstdc++ (shared by default), or libsupc++ (always static). If
819 # you care about binary portability between Linux distributions,
820 # you need to either 1) build your own GCC with static C++ libraries
821 # or 2) link using gcc and libsupc++. We choose the latter since
822 # CUPS doesn't (currently) use any of the stdc++ library.
823 #
824 # Previous versions of GCC do not have the reliance on the stdc++
825 # or g++ libraries, so the extra supc++ library is not needed.
826 AC_MSG_CHECKING(if libsupc++ is required)
827
828 SUPC="`$CXX -print-file-name=libsupc++.a 2>/dev/null`"
829 case "$SUPC" in
830 libsupc++.a*)
831 # Library not found, so this is an older GCC...
832 LD="$CXX"
833 AC_MSG_RESULT(no)
834 ;;
835 *)
836 # This is gcc 3.x, and it knows of libsupc++, so we need it
837 LIBS="$LIBS -lsupc++"
838 LD="$CC"
839 AC_MSG_RESULT(yes)
840
841 # See if this system has a broken libsupc++ that requires
842 # a workaround (FreeBSD 5.x, 6.x)
843 case $host in
844 *-*-freebsd*)
845 AC_MSG_CHECKING(if libsupc++ is missing __terminate_handler)
846 nm -C --defined-only "$SUPC" 2>/dev/null | grep __terminate_handler > /dev/null
847 if test $? -eq 0 ; then
848 AC_MSG_RESULT(no)
849 else
850 AC_MSG_RESULT(yes -- will attempt workaround)
851 LIBEXTRAOBJ="$LIBEXTRAOBJ libsupc++fix.cpp"
852 fi
853 ;;
854 esac
855 ;;
856 esac
857 fi
So, they are trying to outsmart the compiler in some funky ways...
This is so not good... :-(
Notice that they already have a workaround for a missing symbol, not
unlike the situation we have...
And now we can also see where the explicit -lsupc++ comes from, and
indeed the configure steps properly reports it as well:
checking if libsupc++ is required... yes
So, the real fix IMNSHO would be to use gcc to do the actual link, and
get rid of this ugliness above, probably by changing the condition in
an upstream-acceptable way:
if test -n "$GCC" && test -z "$LD"; then
# Their big comment as-is, followed by:
#
# But don;t do that is the user was smart enough to provide
# their own LD
But even then, I'm not sure that would be upstreamable either, because
LD *is* already earlier in the configure.in:
147 dnl Default linker is gcc
148 if test x$LD = x ; then
149 LD="$CC"
150 fi
So this hunk would probably have to go after this big if, above:
if test -n "$GCC" && test -z "$LD"; then
[...]
fi
dnl Default linker is gcc
if test x$LD = x ; then
LD="$CC"
fi
Rejoice, for we now know why we have the issue! ;-)
Regards,
Yann E. MORIN.
> Fixes:
> http://autobuild.buildroot.org/results/3be/3bedf404de0ea42ee3ba624cded65d310a847af9//
> http://autobuild.buildroot.org/results/6ab/6ab4e8021aad13bc153a6c22e87a77bf2bdc21e0//
>
> Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> Cc: arc-buildroot at synopsys.com
> ---
> Changes since v1:
> -Removed commented lines
>
> package/apcupsd/apcupsd.mk | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/package/apcupsd/apcupsd.mk b/package/apcupsd/apcupsd.mk
> index 410bce9aec..d2001419d6 100644
> --- a/package/apcupsd/apcupsd.mk
> +++ b/package/apcupsd/apcupsd.mk
> @@ -18,6 +18,10 @@ APCUPSD_CONF_ENV += LIBS="`$(PKG_CONFIG_HOST_BINARY) --libs libusb`"
> endif
> endif
>
> +ifeq ($(BR2_arc770d)$(BR2_arc750d)$(BR2_sparc),y)
> +APCUPSD_CONF_ENV += LIBS+="-lstdc++"
> +endif
> +
> ifeq ($(BR2_PACKAGE_APCUPSD_APCSMART),y)
> APCUPSD_CONF_OPTS += --enable-apcsmart
> 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] 5+ messages in thread
* [Buildroot] [PATCH v2] package/apcupsd: add -lstdc++ for ARC7* and SPARC
2020-08-17 7:25 ` Yann E. MORIN
@ 2020-08-17 7:51 ` James Hilliard
2020-08-17 16:15 ` Yann E. MORIN
0 siblings, 1 reply; 5+ messages in thread
From: James Hilliard @ 2020-08-17 7:51 UTC (permalink / raw)
To: buildroot
On Mon, Aug 17, 2020 at 1:25 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>
> Evgeniy, James, All,
>
> On 2020-08-12 20:18 +0300, Evgeniy Didin spake thusly:
> > For some reason apcupsd is not building for ARC700 and SPARC,
> > adding "-lstdc++" solves the issue.
>
> So, as Thomas already replied, this is not an acceptable explanation.
>
> The real question is "why are they forgetting to link with -lstdc++ when
> linking a C++ program to begin with?"
Well from my understanding they are intentionally linking with -lsupc++
instead of -lstdc++, but for some reason -lsupc++ is broken on certain
platforms for linking apcupsd.
See: https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.what_is_libsupcxx
>
> And the reason is that they are using gcc to do the link line-wrapping
> by me for readability):
>
> $ make V=
> /home/ymorin/dev/buildroot/O/host/bin/sparc-linux-gcc -static .obj/options.o \
> .obj/device.o .obj/reports.o .obj/action.o .obj/apcupsd.o .obj/apcnis.o \
> /home/ymorin/dev/buildroot/O/build/apcupsd-3.14.14/src/drivers/libdrivers.a \
> /home/ymorin/dev/buildroot/O/build/apcupsd-3.14.14/src/drivers/apcsmart/libapcsmartdrv.a \
> /home/ymorin/dev/buildroot/O/build/apcupsd-3.14.14/src/lib/libapc.a \
> -o apcupsd -lsupc++ -lpthread
>
> Why are they using 'sparc-linux-gcc'?
>
> Buildroot passes LD='.../sparc-linux-ld' so it's not us passing an
> inappropriate value.
>
> So, investigating further, it turns out that in fact, apcusd is not
> really an autotools package, since it only uses autoconf and not
> automake, so their Makefiles are a not traditional... :-/
>
> That aside, their autoconf/configure.in has this gem:
>
>
> 816 if test -n "$GCC"; then
> 817 # Starting with GCC 3.0, you must link C++ programs against either
> 818 # libstdc++ (shared by default), or libsupc++ (always static). If
> 819 # you care about binary portability between Linux distributions,
> 820 # you need to either 1) build your own GCC with static C++ libraries
> 821 # or 2) link using gcc and libsupc++. We choose the latter since
> 822 # CUPS doesn't (currently) use any of the stdc++ library.
> 823 #
> 824 # Previous versions of GCC do not have the reliance on the stdc++
> 825 # or g++ libraries, so the extra supc++ library is not needed.
> 826 AC_MSG_CHECKING(if libsupc++ is required)
> 827
> 828 SUPC="`$CXX -print-file-name=libsupc++.a 2>/dev/null`"
> 829 case "$SUPC" in
> 830 libsupc++.a*)
> 831 # Library not found, so this is an older GCC...
> 832 LD="$CXX"
> 833 AC_MSG_RESULT(no)
> 834 ;;
> 835 *)
> 836 # This is gcc 3.x, and it knows of libsupc++, so we need it
> 837 LIBS="$LIBS -lsupc++"
> 838 LD="$CC"
> 839 AC_MSG_RESULT(yes)
> 840
> 841 # See if this system has a broken libsupc++ that requires
> 842 # a workaround (FreeBSD 5.x, 6.x)
> 843 case $host in
> 844 *-*-freebsd*)
> 845 AC_MSG_CHECKING(if libsupc++ is missing __terminate_handler)
> 846 nm -C --defined-only "$SUPC" 2>/dev/null | grep __terminate_handler > /dev/null
> 847 if test $? -eq 0 ; then
> 848 AC_MSG_RESULT(no)
> 849 else
> 850 AC_MSG_RESULT(yes -- will attempt workaround)
> 851 LIBEXTRAOBJ="$LIBEXTRAOBJ libsupc++fix.cpp"
> 852 fi
> 853 ;;
> 854 esac
> 855 ;;
> 856 esac
> 857 fi
>
> So, they are trying to outsmart the compiler in some funky ways...
> This is so not good... :-(
>
> Notice that they already have a workaround for a missing symbol, not
> unlike the situation we have...
>
> And now we can also see where the explicit -lsupc++ comes from, and
> indeed the configure steps properly reports it as well:
>
> checking if libsupc++ is required... yes
>
> So, the real fix IMNSHO would be to use gcc to do the actual link, and
> get rid of this ugliness above, probably by changing the condition in
> an upstream-acceptable way:
>
> if test -n "$GCC" && test -z "$LD"; then
> # Their big comment as-is, followed by:
> #
> # But don;t do that is the user was smart enough to provide
> # their own LD
>
> But even then, I'm not sure that would be upstreamable either, because
> LD *is* already earlier in the configure.in:
>
> 147 dnl Default linker is gcc
> 148 if test x$LD = x ; then
> 149 LD="$CC"
> 150 fi
>
> So this hunk would probably have to go after this big if, above:
>
> if test -n "$GCC" && test -z "$LD"; then
> [...]
> fi
>
> dnl Default linker is gcc
> if test x$LD = x ; then
> LD="$CC"
> fi
>
> Rejoice, for we now know why we have the issue! ;-)
They are doing a bunch of hacks for sure but what I don't see yet is
why -lsupc++
linking is broken on these specific platforms and no others.
>
> Regards,
> Yann E. MORIN.
>
> > Fixes:
> > http://autobuild.buildroot.org/results/3be/3bedf404de0ea42ee3ba624cded65d310a847af9//
> > http://autobuild.buildroot.org/results/6ab/6ab4e8021aad13bc153a6c22e87a77bf2bdc21e0//
> >
> > Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
> > Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> > Cc: arc-buildroot at synopsys.com
> > ---
> > Changes since v1:
> > -Removed commented lines
> >
> > package/apcupsd/apcupsd.mk | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/package/apcupsd/apcupsd.mk b/package/apcupsd/apcupsd.mk
> > index 410bce9aec..d2001419d6 100644
> > --- a/package/apcupsd/apcupsd.mk
> > +++ b/package/apcupsd/apcupsd.mk
> > @@ -18,6 +18,10 @@ APCUPSD_CONF_ENV += LIBS="`$(PKG_CONFIG_HOST_BINARY) --libs libusb`"
> > endif
> > endif
> >
> > +ifeq ($(BR2_arc770d)$(BR2_arc750d)$(BR2_sparc),y)
> > +APCUPSD_CONF_ENV += LIBS+="-lstdc++"
> > +endif
> > +
> > ifeq ($(BR2_PACKAGE_APCUPSD_APCSMART),y)
> > APCUPSD_CONF_OPTS += --enable-apcsmart
> > 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] 5+ messages in thread
* [Buildroot] [PATCH v2] package/apcupsd: add -lstdc++ for ARC7* and SPARC
2020-08-17 7:51 ` James Hilliard
@ 2020-08-17 16:15 ` Yann E. MORIN
2020-08-17 16:30 ` James Hilliard
0 siblings, 1 reply; 5+ messages in thread
From: Yann E. MORIN @ 2020-08-17 16:15 UTC (permalink / raw)
To: buildroot
James, All,
On 2020-08-17 01:51 -0600, James Hilliard spake thusly:
> On Mon, Aug 17, 2020 at 1:25 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > Evgeniy, James, All,
> >
> > On 2020-08-12 20:18 +0300, Evgeniy Didin spake thusly:
> > > For some reason apcupsd is not building for ARC700 and SPARC,
> > > adding "-lstdc++" solves the issue.
> >
> > So, as Thomas already replied, this is not an acceptable explanation.
> >
> > The real question is "why are they forgetting to link with -lstdc++ when
> > linking a C++ program to begin with?"
> Well from my understanding they are intentionally linking with -lsupc++
> instead of -lstdc++, but for some reason -lsupc++ is broken on certain
> platforms for linking apcupsd.
> See: https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.what_is_libsupcxx
Fact is, I don't understand *why* they would write a C++ program and not
link with the g++ compiler.
The rationales exposed bu apcupsd are:
- that CUPS does not have a dependency on C++, but that is not even true
nowadays;
- that they need to be binary-portable across distributions, which is
somewhat useless for distros as they do build from scratch, and we
do also build from source and are not caring about portability.
So I'm still unsure why using gcc, but I think that trying (and failing)
to reinvent the linker logic is flawed IMHO.
So, my opinion is still that we should use g++ to do the link of a C++
program.
Besides, we're not going to fix existing toolchains and we need to move
forward.
I'm siding with Thomas here, that adding the explicit linking with
-lstdc++ is not the ebst way to solve it, adn rather that we want to
patch configure to use g++ to link.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| 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] 5+ messages in thread
* [Buildroot] [PATCH v2] package/apcupsd: add -lstdc++ for ARC7* and SPARC
2020-08-17 16:15 ` Yann E. MORIN
@ 2020-08-17 16:30 ` James Hilliard
0 siblings, 0 replies; 5+ messages in thread
From: James Hilliard @ 2020-08-17 16:30 UTC (permalink / raw)
To: buildroot
On Mon, Aug 17, 2020 at 10:15 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>
> James, All,
>
> On 2020-08-17 01:51 -0600, James Hilliard spake thusly:
> > On Mon, Aug 17, 2020 at 1:25 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > > Evgeniy, James, All,
> > >
> > > On 2020-08-12 20:18 +0300, Evgeniy Didin spake thusly:
> > > > For some reason apcupsd is not building for ARC700 and SPARC,
> > > > adding "-lstdc++" solves the issue.
> > >
> > > So, as Thomas already replied, this is not an acceptable explanation.
> > >
> > > The real question is "why are they forgetting to link with -lstdc++ when
> > > linking a C++ program to begin with?"
> > Well from my understanding they are intentionally linking with -lsupc++
> > instead of -lstdc++, but for some reason -lsupc++ is broken on certain
> > platforms for linking apcupsd.
> > See: https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.what_is_libsupcxx
>
> Fact is, I don't understand *why* they would write a C++ program and not
> link with the g++ compiler.
>
> The rationales exposed bu apcupsd are:
>
> - that CUPS does not have a dependency on C++, but that is not even true
> nowadays;
>
> - that they need to be binary-portable across distributions, which is
> somewhat useless for distros as they do build from scratch, and we
> do also build from source and are not caring about portability.
>
> So I'm still unsure why using gcc, but I think that trying (and failing)
> to reinvent the linker logic is flawed IMHO.
I think they are just trying to avoid the libstdc++ dependency, which
could save a good amount of disk space if no other apps require libstdc++.
>
> So, my opinion is still that we should use g++ to do the link of a C++
> program.
Maybe, although that seems more of a decision for upstream to make.
However what they are doing is documented as supported behavior it
seems so I'm not really sure it's wrong.
>
> Besides, we're not going to fix existing toolchains and we need to move
> forward.
>
> I'm siding with Thomas here, that adding the explicit linking with
> -lstdc++ is not the ebst way to solve it, adn rather that we want to
> patch configure to use g++ to link.
Well I figure the explicit linking for the bugged toolchains is a decent
enough workaround for now, and easier than trying to patch their
crazy configure scripts.
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> | 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] 5+ messages in thread
end of thread, other threads:[~2020-08-17 16:30 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-12 17:18 [Buildroot] [PATCH v2] package/apcupsd: add -lstdc++ for ARC7* and SPARC Evgeniy Didin
2020-08-17 7:25 ` Yann E. MORIN
2020-08-17 7:51 ` James Hilliard
2020-08-17 16:15 ` Yann E. MORIN
2020-08-17 16:30 ` James Hilliard
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.