Skip to contentSkip to conversation

openvmtools: enable for uClibc toolchains

PATCH New Waldemar Brodkorb 3 participants 5 messages Dec 4, 2015 – Dec 13, 2015

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 openvmtools: enable for uClibc toolchains

Since uClibc-ng 1.0.9 openvmtools can be compiled as the missing euidaccess function was added.

---
 package/openvmtools/Config.in |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
package/openvmtools/Config.in +3 -5
index 64bf65c..528ddbe 100644
@@ -6,7 +6,6 @@ config BR2_PACKAGE_OPENVMTOOLS
 	depends on BR2_TOOLCHAIN_HAS_THREADS # libglib2
 	depends on BR2_TOOLCHAIN_HAS_NATIVE_RPC
 	depends on BR2_ENABLE_LOCALE
-	depends on !BR2_TOOLCHAIN_USES_UCLIBC
 	select BR2_PACKAGE_LIBGLIB2
 	select BR2_PACKAGE_LIBDNET
 	help
@@ -41,14 +40,13 @@ config BR2_PACKAGE_OPENVMTOOLS_PAM
 	help
 	  Support for PAM in openvmtools
 
-comment "PAM support needs an (e)glibc toolchain w/ dynamic library"
+comment "PAM support needs an (e)glibc or uClibc toolchain w/ dynamic library"
 	depends on BR2_STATIC_LIBS || BR2_TOOLCHAIN_USES_MUSL
 
 endif
 
-comment "openvmtools needs an (e)glibc or musl toolchain w/ wchar, threads, RPC, locale"
+comment "openvmtools needs a toolchain w/ wchar, threads, RPC, locale"
 	depends on BR2_i386 || BR2_x86_64
 	depends on BR2_USE_MMU
 	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS || \
-		!BR2_TOOLCHAIN_HAS_NATIVE_RPC || !BR2_ENABLE_LOCALE || \
-		BR2_TOOLCHAIN_USES_UCLIBC
+		!BR2_TOOLCHAIN_HAS_NATIVE_RPC || !BR2_ENABLE_LOCALE
Signature · 1 line
1.7.10.4
#1 lore raw

PATCH 1/1 openvmtools: enable for uClibc toolchains

Waldemar, all,

Quoted 2 lines · Waldemar Brodkorb

Since uClibc-ng 1.0.9 openvmtools can be compiled as the missing euidaccess function was added.

We actually still support older uClibc-based toolchains, including an internal
one based on 0.9.33.2, custom external ones (buildroot or crosstool-NG) that may also be based on that, custom external ones based on -ng pre-1.0.9, and the Blackfin toolchains.

This comment is not specific for this patch but rather applies to all packages
that will work with -ng but not with 0.9.33.2, and there are ever more of those.

There are several things we can do here:

- Ignore it and let the user deal with the build failure.

- Ignore it and add a comment in the Config.in, so that the user at least is warned. See e.g. rt-tests. This is not a great solution either because the user will not see the comment when there is another package that selects openvmtools.

- Depend on an internal -ng toolchain. That sucks pretty hard because you'll often want to build the toolchain once and then use it as an external toolchain.

- Kill 0.9.33.2 and depend on an internal toolchain. See above.

- Give a more explicit warning in the custom external toolchain and in the 0.9.33.x and snapshot uClibc version choices that some packages may fail to build. This should be combined with an explicit exclusion of the Blackfin binaries (not necessary for openvmtools since it depends on MMU).

- Explicitly exclude non-ng toolchains. We can add a hidden symbol for that, and add -ng as a separate option for the custom external toolchain. For this particular patch, that doesn't solve the issue however because it will still fail with uclibc-ng 1.0.8.

I don't think any of these options is perfect, but the last one is the least
bad IMO.

Note that we probably already have a bunch of packages that have this problem,
because the only uClibc-based toolchains that we test in the autobuilders are Buildroot-generated, except for the Blackfin ones.

We probably should kill the non-ng options in the uclibc package as well. We
also should make it more explicit in the documentation of the custom external toolchains that you're on your own.

Otherwise, the patch looks good to me though :-)

Regards,
Arnout

Quoted 37 lines
---
 package/openvmtools/Config.in |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
package/openvmtools/Config.in +3 -5
index 64bf65c..528ddbe 100644
@@ -6,7 +6,6 @@ config BR2_PACKAGE_OPENVMTOOLS
 	depends on BR2_TOOLCHAIN_HAS_THREADS # libglib2
 	depends on BR2_TOOLCHAIN_HAS_NATIVE_RPC
 	depends on BR2_ENABLE_LOCALE
-	depends on !BR2_TOOLCHAIN_USES_UCLIBC
 	select BR2_PACKAGE_LIBGLIB2
 	select BR2_PACKAGE_LIBDNET
 	help
@@ -41,14 +40,13 @@ config BR2_PACKAGE_OPENVMTOOLS_PAM
 	help
 	  Support for PAM in openvmtools
 
-comment "PAM support needs an (e)glibc toolchain w/ dynamic library"
+comment "PAM support needs an (e)glibc or uClibc toolchain w/ dynamic library"
 	depends on BR2_STATIC_LIBS || BR2_TOOLCHAIN_USES_MUSL
 
 endif
 
-comment "openvmtools needs an (e)glibc or musl toolchain w/ wchar, threads, RPC, locale"
+comment "openvmtools needs a toolchain w/ wchar, threads, RPC, locale"
 	depends on BR2_i386 || BR2_x86_64
 	depends on BR2_USE_MMU
 	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS || \
-		!BR2_TOOLCHAIN_HAS_NATIVE_RPC || !BR2_ENABLE_LOCALE || \
-		BR2_TOOLCHAIN_USES_UCLIBC
+		!BR2_TOOLCHAIN_HAS_NATIVE_RPC || !BR2_ENABLE_LOCALE
Signature · 6 lines
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
#2 lore raw

PATCH 1/1 openvmtools: enable for uClibc toolchains

Hi Arnout,
Arnout Vandecappelle wrote,

Quoted 14 lines

Waldemar, all,

Quoted 2 lines · Waldemar Brodkorb

Since uClibc-ng 1.0.9 openvmtools can be compiled as the missing euidaccess function was added.

We actually still support older uClibc-based toolchains, including an internal
one based on 0.9.33.2, custom external ones (buildroot or crosstool-NG) that may also be based on that, custom external ones based on -ng pre-1.0.9, and the Blackfin toolchains.

This comment is not specific for this patch but rather applies to all packages
that will work with -ng but not with 0.9.33.2, and there are ever more of those.

Quoted 7 lines

There are several things we can do here:

- Ignore it and let the user deal with the build failure.

- Ignore it and add a comment in the Config.in, so that the user at least is warned. See e.g. rt-tests. This is not a great solution either because the user will not see the comment when there is another package that selects openvmtools.

I don't think any package selects openvmtools. So this would be okay?

Quoted 9 lines

- Depend on an internal -ng toolchain. That sucks pretty hard because you'll often want to build the toolchain once and then use it as an external toolchain.

- Kill 0.9.33.2 and depend on an internal toolchain. See above.

- Give a more explicit warning in the custom external toolchain and in the 0.9.33.x and snapshot uClibc version choices that some packages may fail to build. This should be combined with an explicit exclusion of the Blackfin binaries (not necessary for openvmtools since it depends on MMU).

Openvm-tools is x86/x86_64 only, so other architectures are not involved anyway.

Quoted 10 lines

- Explicitly exclude non-ng toolchains. We can add a hidden symbol for that, and add -ng as a separate option for the custom external toolchain. For this particular patch, that doesn't solve the issue however because it will still fail with uclibc-ng 1.0.8.

I don't think any of these options is perfect, but the last one is the least
bad IMO.

Quoted 7 lines

Note that we probably already have a bunch of packages that have this problem,
because the only uClibc-based toolchains that we test in the autobuilders are Buildroot-generated, except for the Blackfin ones.

We probably should kill the non-ng options in the uclibc package as well. We
also should make it more explicit in the documentation of the custom external toolchains that you're on your own.

That would be the best, but I am a bit biased ;) uClibc upstream master get no updates since 5 months or so. I think even the snapshot version is getting of no use ;)

Quoted 1 line

Otherwise, the patch looks good to me though :-)

Okay ;)

best regards
Waldemar

#3 lore raw

PATCH 1/1 openvmtools: enable for uClibc toolchains

In reply to Waldemar Brodkorb

Dear Waldemar Brodkorb,

Quoted 7 lines · Waldemar Brodkorb

Since uClibc-ng 1.0.9 openvmtools can be compiled as the missing euidaccess function was added.

---
 package/openvmtools/Config.in |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

Arnout explained very well that this patch is not super great due to the need to keep things working with older uClibc toolchains. Could you instead cook a patch that changes openvmtools to detect if euidaccess() is available or not. If it is available, then it uses it, otherwise, it open-codes it (the euidaccess implementation in uClibc is just one line, so it's not a big deal to copy that in the openvmtools source code).

Are you willing to implement such a solution?

I'd say that within 6/12 months, we should be able to kill non-ng uClibc support. Blackfin will be a problem... but Blackfin has always been a problem.

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 openvmtools: enable for uClibc toolchains

Hi Thomas,
Thomas Petazzoni wrote,

Quoted 19 lines

Dear Waldemar Brodkorb,

Quoted 7 lines · Waldemar Brodkorb

Since uClibc-ng 1.0.9 openvmtools can be compiled as the missing euidaccess function was added.

---
 package/openvmtools/Config.in |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

Arnout explained very well that this patch is not super great due to the need to keep things working with older uClibc toolchains. Could you instead cook a patch that changes openvmtools to detect if euidaccess() is available or not. If it is available, then it uses it, otherwise, it open-codes it (the euidaccess implementation in uClibc is just one line, so it's not a big deal to copy that in the openvmtools source code).

Quoted 1 line

Are you willing to implement such a solution?

Not sure it is worth. I am not using openvmtools on embedded systems, so may be I just wait ;)

Quoted 3 lines

I'd say that within 6/12 months, we should be able to kill non-ng uClibc support. Blackfin will be a problem... but Blackfin has always been a problem.

I recently done some testing with Blackfin. Latest binutils/gcc development versions might be usable to get back an internal toolchain support, whenever they make a new release. (speaking about binutils 2.26 and gcc 6).

best regards
Waldemar