Skip to contentSkip to conversation

toolchain: add support for glibc

PATCH New Thomas Petazzoni 2 participants 11 messages Aug 18, 2013 – Aug 30, 2013

lore
Share & tools
lore

Thomas Petazzoni

author
#0 lore raw

PATCH 1/1 toolchain: add support for glibc

The support for eglibc 2.17 was added to the internal toolchain backend for 2013.08. This commit now adds glibc 2.18 support to the internal toolchain backend. The building procedure is very similar to the one of eglibc, with a few differences, but the two are kept separate for now.

Signed-off-by Thomas Petazzoni <[email protected]>
---
 package/gcc/Config.in.host              |   2 +-
 package/glibc/glibc.mk                  | 105 ++++++++++++++++++++++++++++++++
 toolchain/toolchain-buildroot/Config.in |  20 ++++++
 3 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100644 package/glibc/glibc.mk
package/gcc/Config.in.host +1 -1
index a6acaa2..0b04b90 100644
@@ -119,7 +119,7 @@ config BR2_INSTALL_FORTRAN
 config BR2_GCC_ENABLE_TLS
 	bool "Enable compiler tls support" if BR2_TOOLCHAIN_BUILDROOT_UCLIBC
 	default y
-	depends on BR2_PTHREADS_NATIVE || BR2_TOOLCHAIN_BUILDROOT_EGLIBC
+	depends on BR2_PTHREADS_NATIVE || BR2_TOOLCHAIN_BUILDROOT_EGLIBC || BR2_TOOLCHAIN_BUILDROOT_GLIBC
 	help
 	  Enable the compiler to generate code for accessing
 	  thread local storage variables
package/glibc/glibc.mk new file +105 -0

105 lines not on this page · raw message

toolchain/toolchain-buildroot/Config.in +20 -0
index 396a434..02efdbf 100644
@@ -34,12 +34,32 @@ config BR2_TOOLCHAIN_BUILDROOT_EGLIBC
 
 	  http://eglibc.org
 
+config BR2_TOOLCHAIN_BUILDROOT_GLIBC
+	bool "glibc (experimental)"
+	depends on BR2_arm    || BR2_armeb    || BR2_aarch64 || \
+		   BR2_i386   || BR2_mips     || BR2_mipsel  || \
+		   BR2_mips64 || BR2_mips64el || BR2_powerpc || \
+		   BR2_sh     || BR2_sh64     || BR2_sparc   || \
+		   BR2_x86_64
+	select BR2_TOOLCHAIN_USES_GLIBC
+	# our glibc.mk enables RPC support
+	select BR2_TOOLCHAIN_HAS_NATIVE_RPC
+	help
+	  This option selects glibc as the C library for the
+	  cross-compilation toolchain.
+
+	  The glibc support in the Buildroot toolchain backend is
+	  very recent, and therefore marked experimental.
+
+	  http://www.gnu.org/software/libc/
+
 endchoice
 
 config BR2_TOOLCHAIN_BUILDROOT_LIBC
 	string
 	default "uclibc" if BR2_TOOLCHAIN_BUILDROOT_UCLIBC
 	default "eglibc" if BR2_TOOLCHAIN_BUILDROOT_EGLIBC
+	default "glibc"  if BR2_TOOLCHAIN_BUILDROOT_GLIBC
 
 source "package/uclibc/Config.in"
Signature · 1 line
1.8.1.2
#1 lore raw

PATCH 1/1 toolchain: add support for glibc

Quoted 5 lines · Thomas Petazzoni

The support for eglibc 2.17 was added to the internal toolchain backend for 2013.08. This commit now adds glibc 2.18 support to the internal toolchain backend. The building procedure is very similar to the one of eglibc, with a few differences, but the two are kept separate for now.

I'm not sure if that's a good idea... Will merging them later be easier?

[snip]

package/glibc/glibc.mk line 44

Quoted 6 lines
package/glibc/glibc.mk new file +6 -0
+define GLIBC_CONFIGURE_CMDS
+	mkdir -p $(@D)/build
+	# Do the configuration
+	(cd $(@D)/build; \
+		$(TARGET_CONFIGURE_OPTS) \
+		CFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" CPPFLAGS="" \

The -O2 was required for eglibc. Why do we have it here as well?

[snip]

package/glibc/glibc.mk line 90

Quoted 3 lines
package/glibc/glibc.mk new file +3 -0
+ifeq ($(BR2_PACKAGE_GDB_SERVER),y)
+GLIBC_LIBS_LIB += libthread_db.so
+endif

Shouldn't this lib be installed as well for a gdb without gdbserver?
I.e., shouldn't the condition be ifeq ($(BR2_PACKAGE_GDB),y)?

[snip]

Regards,
Arnout

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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
author
#2 lore raw

PATCH 1/1 toolchain: add support for glibc

Dear Arnout Vandecappelle,

Quoted 8 lines · Arnout Vandecappelle
Quoted 5 lines · Thomas Petazzoni

The support for eglibc 2.17 was added to the internal toolchain backend for 2013.08. This commit now adds glibc 2.18 support to the internal toolchain backend. The building procedure is very similar to the one of eglibc, with a few differences, but the two are kept separate for now.

I'm not sure if that's a good idea... Will merging them later be easier?

I don't know for sure, but the package aren't that complex, so I don't think merging would be very difficult.

If I had to merge them, where should I put the common code?

Quoted 9 lines

[snip]

package/glibc/glibc.mk line 44

Quoted 6 lines
package/glibc/glibc.mk new file +6 -0
+define GLIBC_CONFIGURE_CMDS
+	mkdir -p $(@D)/build
+	# Do the configuration
+	(cd $(@D)/build; \
+		$(TARGET_CONFIGURE_OPTS) \
+		CFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" CPPFLAGS="" \

The -O2 was required for eglibc. Why do we have it here as well?

I believe yes. At least, Crosstool-NG does it, AFAIK. The glibc and eglibc code base are very very similar, so it wouldn't surprise me that the same 'constraint' applies on both.

Quoted 7 lines

[snip]

package/glibc/glibc.mk line 90

Quoted 3 lines
package/glibc/glibc.mk new file +3 -0
+ifeq ($(BR2_PACKAGE_GDB_SERVER),y)
+GLIBC_LIBS_LIB += libthread_db.so
+endif

Shouldn't this lib be installed as well for a gdb without gdbserver?
I.e., shouldn't the condition be ifeq ($(BR2_PACKAGE_GDB),y)?

That's a good question, I don't know. At the moment, the ct-ng backend, the external backend and the eglibc .mk file all copy libthread_db.so when gdbserver is enabled.

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#3 lore raw

PATCH 1/1 toolchain: add support for glibc

Quoted 10 lines · Thomas Petazzoni

Dear Arnout Vandecappelle,

Quoted 7 lines · Arnout Vandecappelle
Quoted 5 lines · Thomas Petazzoni

The support for eglibc 2.17 was added to the internal toolchain backend for 2013.08. This commit now adds glibc 2.18 support to the internal toolchain backend. The building procedure is very similar to the one of eglibc, with a few differences, but the two are kept separate for now.

Quoted 6 lines
Quoted 1 line

I'm not sure if that's a good idea... Will merging them later be easier?

I don't know for sure, but the package aren't that complex, so I don't think merging would be very difficult.

If I had to merge them, where should I put the common code?

I was thinking to have just one glibc package, with a choice to select
eglibc or glibc.

Quoted 23 lines
Quoted 10 lines

[snip]

package/glibc/glibc.mk line 44

Quoted 6 lines
package/glibc/glibc.mk new file +6 -0
+define GLIBC_CONFIGURE_CMDS
+	mkdir -p $(@D)/build
+	# Do the configuration
+	(cd $(@D)/build; \
+		$(TARGET_CONFIGURE_OPTS) \
+		CFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" CPPFLAGS="" \

The -O2 was required for eglibc. Why do we have it here as well?

I believe yes. At least, Crosstool-NG does it, AFAIK. The glibc and eglibc code base are very very similar, so it wouldn't surprise me that the same 'constraint' applies on both.

Quoted 7 lines

[snip]

package/glibc/glibc.mk line 90

Quoted 3 lines
package/glibc/glibc.mk new file +3 -0
+ifeq ($(BR2_PACKAGE_GDB_SERVER),y)
+GLIBC_LIBS_LIB += libthread_db.so
+endif

Shouldn't this lib be installed as well for a gdb without gdbserver?
I.e., shouldn't the condition be ifeq ($(BR2_PACKAGE_GDB),y)?

Quoted 3 lines

That's a good question, I don't know. At the moment, the ct-ng backend, the external backend and the eglibc .mk file all copy libthread_db.so when gdbserver is enabled.

To be tested but it'd surprise me if gdb didn't need it.

Regards,
Arnout

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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
author
#4 lore raw

PATCH 1/1 toolchain: add support for glibc

Dear Arnout Vandecappelle,

Quoted 7 lines · Arnout Vandecappelle
Quoted 4 lines

I don't know for sure, but the package aren't that complex, so I don't think merging would be very difficult.

If I had to merge them, where should I put the common code?

I was thinking to have just one glibc package, with a choice to select
eglibc or glibc.

Well, I still would like the libc selection to be uClibc/glibc/eglibc in the choice in toolchain/toolchain-buildroot/Config.in. But I guess I can probably make BR2_TOOLCHAIN_BUILDROOT_LIBC be equal to "glibc" in both the glibc and eglibc case, which would be sufficient to make the toolchain building logic use the "glibc" and "glibc-configure" targets for both the eglibc and glibc selections.

Want me to rework the patch in this direction?

Note that later on, if we support several versions of glibc and eglibc, then package/glibc/Config.in would look like:

if BR2_TOOLCHAIN_BUILDROOT_EGLIBC

... versions of eglibc ...

endif

if BR2_TOOLCHAIN_BUILDROOT_GLIBC

... versions of glibc ...

endif

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

Shouldn't this lib be installed as well for a gdb without gdbserver?
I.e., shouldn't the condition be ifeq ($(BR2_PACKAGE_GDB),y)?

That's a good question, I don't know. At the moment, the ct-ng backend, the external backend and the eglibc .mk file all copy libthread_db.so when gdbserver is enabled.

To be tested but it'd surprise me if gdb didn't need it.

I agree, it would have to be tested.

Thanks for your feedback,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#5 lore raw

PATCH 1/1 toolchain: add support for glibc

Hi Thomas,

While testing your patch again, I discovered that "make source" doesn't
fetch the glibc source (same for eglibc) because BR2_PACKAGE_EGLIBC is not y. This would be nice to fix still in 2013.08.

Quoted 7 lines · Thomas Petazzoni

Dear Arnout Vandecappelle,

Quoted 3 lines · Arnout Vandecappelle
Quoted 3 lines

I don't know for sure, but the package aren't that complex, so I don't think merging would be very difficult.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

If I had to merge them, where should I put the common code?

I was thinking to have just one glibc package, with a choice to select
eglibc or glibc.

Well, I still would like the libc selection to be uClibc/glibc/eglibc in the choice in toolchain/toolchain-buildroot/Config.in.

Good point.

Quoted 5 lines

But I guess I
can probably make BR2_TOOLCHAIN_BUILDROOT_LIBC be equal to "glibc" in both the glibc and eglibc case, which would be sufficient to make the toolchain building logic use the "glibc" and "glibc-configure" targets for both the eglibc and glibc selections.

You could also choose to keep eglibc.mk and make glibc the derivative.
Or would that be strange?

Quoted 2 lines

Want me to rework the patch in this direction?

Would be nice, but as you say, merging later wouldn't be so difficult.
Except of course that by that time they may have diverged more.

Quoted 7 lines

Note that later on, if we support several versions of glibc and eglibc, then package/glibc/Config.in would look like:

if BR2_TOOLCHAIN_BUILDROOT_EGLIBC

... versions of eglibc ...

Quoted 7 lines

endif

if BR2_TOOLCHAIN_BUILDROOT_GLIBC

... versions of glibc ...

endif

Nothing wrong with that, right?

Regards,
Arnout

Quoted 15 lines
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

Shouldn't this lib be installed as well for a gdb without gdbserver?
I.e., shouldn't the condition be ifeq ($(BR2_PACKAGE_GDB),y)?

That's a good question, I don't know. At the moment, the ct-ng backend, the external backend and the eglibc .mk file all copy libthread_db.so when gdbserver is enabled.

To be tested but it'd surprise me if gdb didn't need it.

I agree, it would have to be tested.

Thanks for your feedback,

Thomas

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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
author
#6 lore raw

PATCH 1/1 toolchain: add support for glibc

Dear Arnout Vandecappelle,

Quoted 3 lines · Arnout Vandecappelle

While testing your patch again, I discovered that "make source" doesn't
fetch the glibc source (same for eglibc) because BR2_PACKAGE_EGLIBC is not y. This would be nice to fix still in 2013.08.

Generally, 'make source' is unfortunately a bit broken with the new internal toolchain backend based on packages. One of the reason is that the 'make source' thing only works for one recursion level of dependencies on host packages. I've started working on fixing that, but it was more complex than I thought (or alternatively I was too stupid to see that there was a simple solution).

Quoted 8 lines
Quoted 5 lines

But I guess I
can probably make BR2_TOOLCHAIN_BUILDROOT_LIBC be equal to "glibc" in both the glibc and eglibc case, which would be sufficient to make the toolchain building logic use the "glibc" and "glibc-configure" targets for both the eglibc and glibc selections.

You could also choose to keep eglibc.mk and make glibc the derivative.
Or would that be strange?

Have you seen my new patch set:

Subject: [Buildroot] [PATCH 00/12] Toolchain updates
Date: Wed, 28 Aug 2013 08:35:19 +0200

It already incorporates a single 'glibc' package that handles both glibc and eglibc, as per your suggestion. See PATCH 07/12 of this series.

I renamed the package to 'glibc' because with the new activity in glibc, it is expected that eglibc will more or less disappear in the coming months/years. People are talking on how to merge back into glibc the changes that were kept separate in eglibc, etc.

Quoted 4 lines
Quoted 1 line

Want me to rework the patch in this direction?

Would be nice, but as you say, merging later wouldn't be so difficult.
Except of course that by that time they may have diverged more.

It's already done, see above.

Quoted 9 lines
Quoted 9 lines

Note that later on, if we support several versions of glibc and eglibc, then package/glibc/Config.in would look like:

if BR2_TOOLCHAIN_BUILDROOT_EGLIBC

... versions of eglibc ...

endif

Quoted 7 lines
Quoted 5 lines

if BR2_TOOLCHAIN_BUILDROOT_GLIBC

... versions of glibc ...

endif

Nothing wrong with that, right?

No, nothing wrong at all :)

Thanks!

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#7 lore raw

PATCH 1/1 toolchain: add support for glibc

Quoted 8 lines · Thomas Petazzoni

Dear Arnout Vandecappelle,

Quoted 3 lines · Arnout Vandecappelle

While testing your patch again, I discovered that "make source" doesn't
fetch the glibc source (same for eglibc) because BR2_PACKAGE_EGLIBC is not y. This would be nice to fix still in 2013.08.

Quoted 6 lines

Generally, 'make source' is unfortunately a bit broken with the new internal toolchain backend based on packages. One of the reason is that the 'make source' thing only works for one recursion level of dependencies on host packages. I've started working on fixing that, but it was more complex than I thought (or alternatively I was too stupid to see that there was a simple solution).

Probably requires an pkg-generic change, like:

$(2)-all-source: $(2)-source $(suffix -source,$($(2)_DEPENDENCIES))

Quoted 10 lines
Quoted 8 lines
Quoted 5 lines

But I guess I
can probably make BR2_TOOLCHAIN_BUILDROOT_LIBC be equal to "glibc" in both the glibc and eglibc case, which would be sufficient to make the toolchain building logic use the "glibc" and "glibc-configure" targets for both the eglibc and glibc selections.

You could also choose to keep eglibc.mk and make glibc the derivative.
Or would that be strange?

Have you seen my new patch set:

Sorry, I thought I had checked before sending but obviously my search
wasn't good enough.

Quoted 4 lines

Subject: [Buildroot] [PATCH 00/12] Toolchain updates
Date: Wed, 28 Aug 2013 08:35:19 +0200

Quoted 8 lines

It already incorporates a single 'glibc' package that handles both glibc and eglibc, as per your suggestion. See PATCH 07/12 of this series.

I renamed the package to 'glibc' because with the new activity in glibc, it is expected that eglibc will more or less disappear in the coming months/years. People are talking on how to merge back into glibc the changes that were kept separate in eglibc, etc.

Oh, I didn't know that.

Regards,
Arnout

Quoted 31 lines
Quoted 5 lines
Quoted 2 lines

Want me to rework the patch in this direction?

Would be nice, but as you say, merging later wouldn't be so difficult.
Except of course that by that time they may have diverged more.

It's already done, see above.

Quoted 9 lines
Quoted 9 lines

Note that later on, if we support several versions of glibc and eglibc, then package/glibc/Config.in would look like:

if BR2_TOOLCHAIN_BUILDROOT_EGLIBC

... versions of eglibc ...

endif

Quoted 7 lines
Quoted 5 lines

if BR2_TOOLCHAIN_BUILDROOT_GLIBC

... versions of glibc ...

endif

Nothing wrong with that, right?

No, nothing wrong at all :)

Thanks!

Thomas

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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
author
#8 lore raw

PATCH 1/1 toolchain: add support for glibc

Dear Arnout Vandecappelle,

Quoted 10 lines · Arnout Vandecappelle
Quoted 6 lines

Generally, 'make source' is unfortunately a bit broken with the new internal toolchain backend based on packages. One of the reason is that the 'make source' thing only works for one recursion level of dependencies on host packages. I've started working on fixing that, but it was more complex than I thought (or alternatively I was too stupid to see that there was a simple solution).

Probably requires an pkg-generic change, like:

$(2)-all-source: $(2)-source $(suffix -source,$($(2)_DEPENDENCIES))

Hum, right. I'll try to find some time to investigate that.

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines

But I guess I
can probably make BR2_TOOLCHAIN_BUILDROOT_LIBC be equal to "glibc" in both the glibc and eglibc case, which would be sufficient to make the toolchain building logic use the "glibc" and "glibc-configure" targets for both the eglibc and glibc selections.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

You could also choose to keep eglibc.mk and make glibc the derivative.
Or would that be strange?

Have you seen my new patch set:

Sorry, I thought I had checked before sending but obviously my search
wasn't good enough.

No problem. I guess you'll continue the review over here :)

Thanks!

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#9 lore raw

PATCH 1/1 toolchain: add support for glibc

In reply to Thomas Petazzoni

toolchain/toolchain-buildroot/Config.in config BR2_TOOLCHAIN_BUILDROOT_EGLIBC · line 43

Quoted 7 lines · Thomas Petazzoni
toolchain/toolchain-buildroot/Config.in +7 -0
+config BR2_TOOLCHAIN_BUILDROOT_GLIBC
+	bool "glibc (experimental)"
+	depends on BR2_arm    || BR2_armeb    || BR2_aarch64 || \
+		   BR2_i386   || BR2_mips     || BR2_mipsel  || \
+		   BR2_mips64 || BR2_mips64el || BR2_powerpc || \
+		   BR2_sh     || BR2_sh64     || BR2_sparc   || \
+		   BR2_x86_64

I though, let's try this patch with some exotic architecture, and guess
what:

Quoted 1 line
Quoted 1 line
Quoted 1 line

glibc 2.18 Configuring

...
checking sysdep dirs... configure: error: The sh64 is not supported.

Continuing with sparc...

Regards,
Arnout

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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
#10 lore raw

PATCH 1/1 toolchain: add support for glibc

Quoted 12 lines · Arnout Vandecappelle

toolchain/toolchain-buildroot/Config.in config BR2_TOOLCHAIN_BUILDROOT_EGLIBC · line 43

Quoted 7 lines · Thomas Petazzoni
toolchain/toolchain-buildroot/Config.in +7 -0
+config BR2_TOOLCHAIN_BUILDROOT_GLIBC
+    bool "glibc (experimental)"
+    depends on BR2_arm    || BR2_armeb    || BR2_aarch64 || \
+           BR2_i386   || BR2_mips     || BR2_mipsel  || \
+           BR2_mips64 || BR2_mips64el || BR2_powerpc || \
+           BR2_sh     || BR2_sh64     || BR2_sparc   || \
+           BR2_x86_64

I though, let's try this patch with some exotic architecture, and guess
what:

Quoted 6 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line

glibc 2.18 Configuring

...
checking sysdep dirs... configure: error: The sh64 is not supported.

Continuing with sparc...

sparc wouldn't even build gcc-initial, so I continued with powerpc and
that at least worked :-) Given that the two comments I had were minor, you can add my

Tested-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>
Acked-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

Regards,
Arnout

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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F