Skip to contentSkip to conversation

evtest: fix program_invocation_short_name undeclared

PATCH New Peter Seiderer 4 participants 7 messages Mar 19, 2015 – Mar 24, 2015

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 evtest: fix program_invocation_short_name undeclared

Add fallback in case program_invocation_short_name is undeclared, e.g. in case of some uclibc configurations.

Fixes [1]:
evtest.c:730:20: error: 'program_invocation_short_name' undeclared (first use in this function)

    printf("%s %s\n", program_invocation_short_name, PACKAGE_VERSION);

[1] http://autobuild.buildroot.net/results/0fd/0fd36a0d79c4d82aedebb5aca8d3ce4214b1ed61

---
 ...-program_invocation_short_name-undeclared.patch | 50 ++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 package/evtest/0001-fix-program_invocation_short_name-undeclared.patch
package/evtest/0001-fix-program_invocation_short_name-undeclared.patch new file +50 -0
new file mode 100644
index 0000000..17f0fb3
@@ -0,0 +1,50 @@
+From c124b50e13aaff46e7928d66b329644bf9b6dae7 Mon Sep 17 00:00:00 2001
+From: Peter Seiderer <[email protected]>
+Date: Thu, 19 Mar 2015 23:08:34 +0100
+Subject: [PATCH] fix program_invocation_short_name undeclared
+
+Add fallback in case program_invocation_short_name is undeclared,
+e.g. in case of some uclibc configurations.
+
+Signed-off-by: Peter Seiderer <[email protected]>
+---
+ configure.ac | 8 ++++++++
+ evtest.c     | 5 +++++
+ 2 files changed, 13 insertions(+)
+
+diff --git a/configure.ac b/configure.ac
+index 8dabc81..c13b05e 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -22,4 +22,12 @@ if test "x$XMLTO" = "x" || test "x$ASCIIDOC" = "x"; then
+ 	AC_MSG_WARN([xmlto or asciidoc not found - cannot create man pages without it])
+ fi
+ 
++AC_MSG_CHECKING([for program_invocation_short_name])
++AC_TRY_COMPILE([#define _GNU_SOURCE
++		#include <errno.h>], 
++	[strlen(program_invocation_short_name)],
++	AC_DEFINE(HAVE_PROGRAM_INVOCATION_SHORT_NAME, 1,
++		[Defined if program_invocation_short_name is defined])
++	AC_MSG_RESULT(yes), AC_MSG_RESULT(no))
++
+ AC_OUTPUT([Makefile])
+diff --git a/evtest.c b/evtest.c
+index 40bc82b..d601889 100644
+--- a/evtest.c
++++ b/evtest.c
+@@ -86,6 +86,11 @@
+ 
+ #define NAME_ELEMENT(element) [element] = #element
+ 
++/* fallback to canonical name */
++#ifndef HAVE_PROGRAM_INVOCATION_SHORT_NAME
++static char *program_invocation_short_name = "evtest";
++#endif
++
+ enum evtest_mode {
+ 	MODE_CAPTURE,
+ 	MODE_QUERY,
+-- 
+2.1.4
+
Signature · 1 line
2.1.4
#1 lore raw

PATCH 1/1 evtest: fix program_invocation_short_name undeclared

Dear Peter Seiderer,

Adding Alexey from Synopsys in Cc.

Quoted 10 lines · Peter Seiderer

Add fallback in case program_invocation_short_name is undeclared, e.g. in case of some uclibc configurations.

Fixes [1]:
evtest.c:730:20: error: 'program_invocation_short_name' undeclared (first use in this function)

    printf("%s %s\n", program_invocation_short_name, PACKAGE_VERSION);

[1] http://autobuild.buildroot.net/results/0fd/0fd36a0d79c4d82aedebb5aca8d3ce4214b1ed61

Shouldn't we instead ask Synopsys to rebuild their toolchains with a uClibc configuration that includes UCLIBC_HAS_PROGRAM_INVOCATION_NAME=y, so that it matches the default Buildroot uClibc and we don't have to add gazillions of workarounds in multiple packages just to support the ARC external toolchain?

Alexey ?

Thanks,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#2 lore raw

PATCH 1/1 evtest: fix program_invocation_short_name undeclared

Hi Peter,

Quoted 14 lines · Thomas Petazzoni

Dear Peter Seiderer,

Adding Alexey from Synopsys in Cc.

Quoted 9 lines · Peter Seiderer

Add fallback in case program_invocation_short_name is undeclared, e.g. in case of some uclibc configurations.

Fixes [1]:
evtest.c:730:20: error: 'program_invocation_short_name' undeclared (first use in this function)

    printf("%s %s\n", program_invocation_short_name, PACKAGE_VERSION);

[1] http://autobuild.buildroot.net/results/0fd/0fd36a0d79c4d82aedebb5aca8d3ce4214b1ed61

Quoted 8 lines
Quoted 1 line

Shouldn't we instead ask Synopsys to rebuild their toolchains with a uClibc configuration that includes UCLIBC_HAS_PROGRAM_INVOCATION_NAME=y, so that it matches the default Buildroot uClibc and we don't have to add gazillions of workarounds in multiple packages just to support the ARC external toolchain?

Thanks for this report about missing feature.
Indeed this one was disabled (not yet enabled) by 2014.12 release. These are uClibc defconfigs we used for building GNU tools for ARC:

[ARC 700]
https://github.com/foss-for-synopsys-dwc-arc-processors/uClibc/blob/arc-2014.12/extra/Configs/defconfigs/arc/defconfig
[ARC HS]
https://github.com/foss-for-synopsys-dwc-arc-processors/uClibc/blob/arc-2014.12/extra/Configs/defconfigs/arc/arcv2_defconfig

And unfortunately chances are low to rebuild 2014.12 tools with modified configs.

But! We faced some issues when dealing with perf and elfutils and understood that we need to enable both UCLIBC_HAS_PROGRAM_INVOCATION_NAME and UCLIBC_HAS_GLIBC_CUSTOM_STREAMS -
https://github.com/foss-for-synopsys-dwc-arc-processors/uClibc/commit/c2460b9b7b8c76098dfb1313be4aa4a4a65ff619

So in the next release (that we plan to prepare later this spring) we'll have those enabled in prebuilt tools.

And for now I would propose to ignore mentioned build errors. Because indeed there's no point to throw in tons of temporary patches - if anybody really wants those "problematic" packages to be built there's always a possibility to build toolchain in Buildroot and it will use Buildroot's default uClibc config.

Will it work for you?

-Alexey

#3 lore raw

PATCH 1/1 evtest: fix program_invocation_short_name undeclared

Dear Alexey Brodkin,

Quoted 7 lines · Alexey Brodkin

And for now I would propose to ignore mentioned build errors. Because indeed there's no point to throw in tons of temporary patches - if anybody really wants those "problematic" packages to be built there's always a possibility to build toolchain in Buildroot and it will use Buildroot's default uClibc config.

Will it work for you?

Yes, it works. In the mean time, there is a way to avoid the build
errors: add an exception to the autobuilder script. See
http://git.buildroot.net/buildroot-test/tree/scripts/autobuild-run#n346
for a bunch of examples.

Thanks,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#4 lore raw

PATCH 1/1 evtest: fix program_invocation_short_name undeclared

Quoted 11 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Dear Alexey Brodkin,

Quoted 6 lines · Alexey Brodkin

And for now I would propose to ignore mentioned build errors. Because indeed there's no point to throw in tons of temporary patches - if anybody really wants those "problematic" packages to be built there's always a possibility to build toolchain in Buildroot and it will use Buildroot's default uClibc config.

Quoted 6 lines
Quoted 1 line

Will it work for you?

Yes, it works. In the mean time, there is a way to avoid the build
errors: add an exception to the autobuilder script. See
http://git.buildroot.net/buildroot-test/tree/scripts/autobuild-run#n346
for a bunch of examples.

Or simply make the packages depend on !BR2_TOOLCHAIN_EXTERNAL_SYNOPSYS_ARC_2014_12. Peter will you send patches to do that for evtest and libevdev?

Signature · 1 line
Bye, Peter Korsgaard
#5 lore raw

PATCH 1/1 evtest: fix program_invocation_short_name undeclared

Dear Peter Korsgaard,

Quoted 8 lines · Peter Korsgaard
Quoted 4 lines

Yes, it works. In the mean time, there is a way to avoid the build
errors: add an exception to the autobuilder script. See
http://git.buildroot.net/buildroot-test/tree/scripts/autobuild-run#n346
for a bunch of examples.

Or simply make the packages depend on !BR2_TOOLCHAIN_EXTERNAL_SYNOPSYS_ARC_2014_12. Peter will you send patches to do that for evtest and libevdev?

This is indeed OK for packages such as evtest that don't have, or don't have many, reverse dependencies. But this is hardly a sustainable solution in general, especially for packages that have a high number of reverse dependencies.

We simply can't handle all the little possible variations of uClibc configurations that exist in every external toolchain, it's not workable in a general fashion.

I know we're already doing it to some extent, but I'd like to avoid doing it when possible, especially when we have a good cooperation with the upstream developers (in this case, the Synopsys folks).

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#6 lore raw

PATCH 1/1 evtest: fix program_invocation_short_name undeclared

Quoted 10 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Dear Peter Korsgaard,

Quoted 5 lines · Peter Korsgaard
Quoted 4 lines

Yes, it works. In the mean time, there is a way to avoid the build
errors: add an exception to the autobuilder script. See
http://git.buildroot.net/buildroot-test/tree/scripts/autobuild-run#n346
for a bunch of examples.

Quoted 8 lines
Quoted 3 lines

Or simply make the packages depend on !BR2_TOOLCHAIN_EXTERNAL_SYNOPSYS_ARC_2014_12. Peter will you send patches to do that for evtest and libevdev?

This is indeed OK for packages such as evtest that don't have, or don't have many, reverse dependencies. But this is hardly a sustainable solution in general, especially for packages that have a high number of reverse dependencies.

True, with lots of reverse deps it becomes very painful.

Quoted 3 lines

We simply can't handle all the little possible variations of uClibc configurations that exist in every external toolchain, it's not workable in a general fashion.

We don't support that many external uClibc based toolchains (only arc, bfin and sh) so I think it's still doable, but ok.

Quoted 3 lines

I know we're already doing it to some extent, but I'd like to avoid doing it when possible, especially when we have a good cooperation with the upstream developers (in this case, the Synopsys folks).

If we can remove the arc 2014.12 toolchain and add the new 2015 one before 2015.05-rc1 (E.G. end of April) then I'm fine with just disabling it in the autobuilders for now, otherwise I still think we should add the depends on !arc-2014-12 to not break it for users.

Signature · 1 line
Bye, Peter Korsgaard