* compile application header file missing
@ 2011-03-15 10:57 Gerard van den Bosch
2011-03-15 13:38 ` Richard Purdie
0 siblings, 1 reply; 9+ messages in thread
From: Gerard van den Bosch @ 2011-03-15 10:57 UTC (permalink / raw)
To: poky
Hello,
I have programmed an application that uses the OpenSLP library and thus
needs the header file from it.
OpenSLP is already compiled and running fine on the target.
But when I try to compile my application it can't find the header file.
When I print out the CFLAGS with bitbake myimage -e | grep CFLAGS the
BUILD_CFLAGS point to:
/home/gerard/green-3.3/build/tmp/sysroots/i686-linux/usr/include
The slp.h is indeed missing, but it is located at:
/home/gerard/green-3.3/build/tmp/sysroots/armv7a-poky-linux-gnueabi/usr/include
How can I change the CFLAGS to look in the other folder or force OpenSLP
to drop it in the i686 folder?
I have added OpenSLP to my DEPENDS in the recipe, also tried RDEPENDS
but it didn't solve the problem.
Regards,
Gerard
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: compile application header file missing
2011-03-15 10:57 compile application header file missing Gerard van den Bosch
@ 2011-03-15 13:38 ` Richard Purdie
2011-03-15 15:03 ` Gerard van den Bosch
0 siblings, 1 reply; 9+ messages in thread
From: Richard Purdie @ 2011-03-15 13:38 UTC (permalink / raw)
To: Gerard van den Bosch; +Cc: poky
On Tue, 2011-03-15 at 11:57 +0100, Gerard van den Bosch wrote:
> Hello,
>
> I have programmed an application that uses the OpenSLP library and thus
> needs the header file from it.
> OpenSLP is already compiled and running fine on the target.
>
> But when I try to compile my application it can't find the header file.
> When I print out the CFLAGS with bitbake myimage -e | grep CFLAGS the
> BUILD_CFLAGS point to:
> /home/gerard/green-3.3/build/tmp/sysroots/i686-linux/usr/include
> The slp.h is indeed missing, but it is located at:
> /home/gerard/green-3.3/build/tmp/sysroots/armv7a-poky-linux-gnueabi/usr/include
>
> How can I change the CFLAGS to look in the other folder or force OpenSLP
> to drop it in the i686 folder?
>
> I have added OpenSLP to my DEPENDS in the recipe, also tried RDEPENDS
> but it didn't solve the problem.
You should be adding OpenSLP to DEPENDS. The toolchain should be
automatically searching the arm sysroot /usr/include directory for
include files which is where your file is.
I appreciate this is the green release, in master we have this in
meta/conf/bitbake.conf:
TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"
export CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
Back in green, this option should be being hardcoded into gcc as the
default sysroot option but you could try explicitly setting it.
Note that BUILD_CFLAGS is the wrong place to look, those are for native
build tools, not target ones. You want to use TARGET_CFLAGS and
TARGET_CFLAGS should be the same as CFLAGS.
After reading the above, if your image *is* using BUILD_CFLAGS and
BUILD_CC instead of CC, that is your real problem, it should be using
the target device compiler, not the build one.
Cheers,
Richard
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: compile application header file missing
2011-03-15 13:38 ` Richard Purdie
@ 2011-03-15 15:03 ` Gerard van den Bosch
2011-03-16 16:08 ` Richard Purdie
0 siblings, 1 reply; 9+ messages in thread
From: Gerard van den Bosch @ 2011-03-15 15:03 UTC (permalink / raw)
To: Richard Purdie; +Cc: poky
On 03/15/2011 02:38 PM, Richard Purdie wrote:
> On Tue, 2011-03-15 at 11:57 +0100, Gerard van den Bosch wrote:
>> Hello,
>>
>> I have programmed an application that uses the OpenSLP library and thus
>> needs the header file from it.
>> OpenSLP is already compiled and running fine on the target.
>>
>> But when I try to compile my application it can't find the header file.
>> When I print out the CFLAGS with bitbake myimage -e | grep CFLAGS the
>> BUILD_CFLAGS point to:
>> /home/gerard/green-3.3/build/tmp/sysroots/i686-linux/usr/include
>> The slp.h is indeed missing, but it is located at:
>> /home/gerard/green-3.3/build/tmp/sysroots/armv7a-poky-linux-gnueabi/usr/include
>>
>> How can I change the CFLAGS to look in the other folder or force OpenSLP
>> to drop it in the i686 folder?
>>
>> I have added OpenSLP to my DEPENDS in the recipe, also tried RDEPENDS
>> but it didn't solve the problem.
> You should be adding OpenSLP to DEPENDS. The toolchain should be
> automatically searching the arm sysroot /usr/include directory for
> include files which is where your file is.
>
> I appreciate this is the green release, in master we have this in
> meta/conf/bitbake.conf:
>
> TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"
>
> export CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
>
> Back in green, this option should be being hardcoded into gcc as the
> default sysroot option but you could try explicitly setting it.
>
> Note that BUILD_CFLAGS is the wrong place to look, those are for native
> build tools, not target ones. You want to use TARGET_CFLAGS and
> TARGET_CFLAGS should be the same as CFLAGS.
>
> After reading the above, if your image *is* using BUILD_CFLAGS and
> BUILD_CC instead of CC, that is your real problem, it should be using
> the target device compiler, not the build one.
>
> Cheers,
>
> Richard
>
I am indeed using the Green release.
The TARGET_CFLAGS are indeed the same as the CFLAGS. The system is using the default CC and not the BUILD_CC, thanks for pointing out the difference.
I have added the --sysroot option pointing to the arm sysroot to the CFLAGS in my recipe, with compilation it now looks like this:
arm-poky-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb -feliminate-unused-debug-types --sysroot=/home/gerard/green-3.3/build/tmp/sysroots/armv7a-poky-linux-gnueabi/ libxmlpcp.c -o libxmlpcp.o
This removes the missing SLP.h error.
Is this problem related to my recipe or did I broke my build environment?
My recipe looks like this:
DESCRIPTION = "libxmlpcp"
SECTION = "examples"
DEPENDS = "openslp libxml2"
LICENSE = "LGPL"
SRC_URI = "file://libxmlpcp.tar.gz"
CFLAGS += --sysroot=/home/gerard/green-3.3/build/tmp/sysroots/armv7a-poky-linux-gnueabi/
do_install() {
install -d ${D}${libdir}
install -d ${D}${includedir}
oe_runmake 'INSTALLHEADERDIR=${D}${includedir}' 'INSTALLLIBDIR=${D}${libdir}' \
install
}
Regards,
Gerard
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: compile application header file missing
2011-03-15 15:03 ` Gerard van den Bosch
@ 2011-03-16 16:08 ` Richard Purdie
2011-03-17 7:43 ` Gerard van den Bosch
0 siblings, 1 reply; 9+ messages in thread
From: Richard Purdie @ 2011-03-16 16:08 UTC (permalink / raw)
To: Gerard van den Bosch; +Cc: poky
On Tue, 2011-03-15 at 16:03 +0100, Gerard van den Bosch wrote:
> I am indeed using the Green release.
>
> The TARGET_CFLAGS are indeed the same as the CFLAGS. The system is
> using the default CC and not the BUILD_CC, thanks for pointing out the
> difference.
>
> I have added the --sysroot option pointing to the arm sysroot to the
> CFLAGS in my recipe, with compilation it now looks like this:
> arm-poky-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon
> -mfloat-abi=softfp -fno-tree-vectorize -fexpensive-optimizations
> -fomit-frame-pointer -frename-registers -O2 -ggdb
> -feliminate-unused-debug-types
> --sysroot=/home/gerard/green-3.3/build/tmp/sysroots/armv7a-poky-linux-gnueabi/ libxmlpcp.c -o libxmlpcp.o
>
> This removes the missing SLP.h error.
>
> Is this problem related to my recipe or did I broke my build
> environment?
To be honest, I don't know. The compiler should have been defaulting to
that already so I don't understand why it wasn't working. We now
explictly set this in master to allow for toolchain relocation and the
machine specific sysroots support. You could try backporting the piece
of code I previously referred to which should also fix the problem.
If that option were missing from the toolchain I'd have expected you to
see other errors rather than just this isolated problem...
> My recipe looks like this:
> DESCRIPTION = "libxmlpcp"
> SECTION = "examples"
> DEPENDS = "openslp libxml2"
> LICENSE = "LGPL"
>
> SRC_URI = "file://libxmlpcp.tar.gz"
>
> CFLAGS += --sysroot=/home/gerard/green-3.3/build/tmp/sysroots/armv7a-poky-linux-gnueabi/
>
> do_install() {
> install -d ${D}${libdir}
> install -d ${D}${includedir}
> oe_runmake 'INSTALLHEADERDIR=${D}${includedir}' 'INSTALLLIBDIR=${D}${libdir}' \
> install
> }
That all looks reasonable enough...
Cheers,
Richard
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: compile application header file missing
2011-03-16 16:08 ` Richard Purdie
@ 2011-03-17 7:43 ` Gerard van den Bosch
2011-03-17 7:52 ` Khem Raj
0 siblings, 1 reply; 9+ messages in thread
From: Gerard van den Bosch @ 2011-03-17 7:43 UTC (permalink / raw)
To: Richard Purdie; +Cc: poky
On 03/16/2011 05:08 PM, Richard Purdie wrote:
> On Tue, 2011-03-15 at 16:03 +0100, Gerard van den Bosch wrote:
>> I am indeed using the Green release.
>>
>> The TARGET_CFLAGS are indeed the same as the CFLAGS. The system is
>> using the default CC and not the BUILD_CC, thanks for pointing out the
>> difference.
>>
>> I have added the --sysroot option pointing to the arm sysroot to the
>> CFLAGS in my recipe, with compilation it now looks like this:
>> arm-poky-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon
>> -mfloat-abi=softfp -fno-tree-vectorize -fexpensive-optimizations
>> -fomit-frame-pointer -frename-registers -O2 -ggdb
>> -feliminate-unused-debug-types
>> --sysroot=/home/gerard/green-3.3/build/tmp/sysroots/armv7a-poky-linux-gnueabi/ libxmlpcp.c -o libxmlpcp.o
>>
>> This removes the missing SLP.h error.
>>
>> Is this problem related to my recipe or did I broke my build
>> environment?
> To be honest, I don't know. The compiler should have been defaulting to
> that already so I don't understand why it wasn't working. We now
> explictly set this in master to allow for toolchain relocation and the
> machine specific sysroots support. You could try backporting the piece
> of code I previously referred to which should also fix the problem.
>
> If that option were missing from the toolchain I'd have expected you to
> see other errors rather than just this isolated problem...
It also couldn't find libxml headers either but because I thought it was similar to the missing SLP.h I left it out.
I made the changes now to the bitbake conf file like you wrote and it compiles now without having to add the sysroot in my recipe, I have also modified my recipe to pick up libxml also.
DESCRIPTION = "libxmlpcp"
SECTION = "libs"
DEPENDS = "openslp libxml2"
LICENSE = "LGPL"
SRC_URI = "file://libxmlpcp.tar.gz"
EXTRA_OEMAKE = "'CFLAGS=${CFLAGS} -fPIC -c -I${OPIEDIR}${includedir}/libxml2' 'LDFLAGS=${LDFLAGS} -shared -lxml2 -lslp'"
do_install() {
install -d ${D}${libdir}
install -d ${D}${includedir}
oe_runmake 'INSTALLHEADERDIR=${D}${includedir}' 'INSTALLLIBDIR=${D}${libdir}' \
install
}
But when build is done I can not find the lib in the actual rootfs, looking at the date the rootfs is being regenerated.
The lib file exists in the build tree on the following places:
tmp/work/armv7a-poky-linux-gnueabi/libxmlpcp-0.1.0-r0/image/usr/lib
tmp/sysroots/armv7a-poky-linux-gnueabi/usr/lib
libxmlpcp-dbg_0.1.0-r0_armv7a.ipk and libxmlpcp-dev_0.1.0-r0_armv7a.ipk in the tmp/deploy/ipk/armv7a folder.
I only get a "strip" error, can this be the reason it isn't included in the rootfs?
ERROR: runstrip: ''arm-poky-linux-gnueabi-strip' --remove-section=.comment --remove-section=.note --strip-unneeded '/home/gerard/green-3.3/build/tmp/work/armv7a-poky-linux-gnueabi/libxmlpcp-0.1.0-r0/package/usr/lib/libxmlpcp.so'' strip command failed
Because I didn't get soup out of it I installed the laverne release also.
If I build my package with that it also gives the strip error but at the end this gives the error that the do_rootfs failed because it couldn't find the package libxmlpcp.
So I assume this is also the problem in green why my package isn't included in the rootfs only that build doesn't give the error.
I have runned my build with -DDDvv but can't figure out where it searches for my libxmlpcp package.
Regards,
Gerard
>> My recipe looks like this:
>> DESCRIPTION = "libxmlpcp"
>> SECTION = "examples"
>> DEPENDS = "openslp libxml2"
>> LICENSE = "LGPL"
>>
>> SRC_URI = "file://libxmlpcp.tar.gz"
>>
>> CFLAGS += --sysroot=/home/gerard/green-3.3/build/tmp/sysroots/armv7a-poky-linux-gnueabi/
>>
>> do_install() {
>> install -d ${D}${libdir}
>> install -d ${D}${includedir}
>> oe_runmake 'INSTALLHEADERDIR=${D}${includedir}' 'INSTALLLIBDIR=${D}${libdir}' \
>> install
>> }
> That all looks reasonable enough...
>
> Cheers,
>
> Richard
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: compile application header file missing
2011-03-17 7:43 ` Gerard van den Bosch
@ 2011-03-17 7:52 ` Khem Raj
2011-03-17 8:00 ` Gerard van den Bosch
0 siblings, 1 reply; 9+ messages in thread
From: Khem Raj @ 2011-03-17 7:52 UTC (permalink / raw)
To: Gerard van den Bosch; +Cc: poky
> DESCRIPTION = "libxmlpcp"
> SECTION = "libs"
> DEPENDS = "openslp libxml2"
> LICENSE = "LGPL"
>
> SRC_URI = "file://libxmlpcp.tar.gz"
>
> EXTRA_OEMAKE = "'CFLAGS=${CFLAGS} -fPIC -c -I${OPIEDIR}${includedir}/libxml2' 'LDFLAGS=${LDFLAGS} -shared -lxml2 -lslp'"
>
> do_install() {
> install -d ${D}${libdir}
> install -d ${D}${includedir}
> oe_runmake 'INSTALLHEADERDIR=${D}${includedir}' 'INSTALLLIBDIR=${D}${libdir}' \
> install
> }
>
> But when build is done I can not find the lib in the actual rootfs, looking at the date the rootfs is being regenerated.
>
> The lib file exists in the build tree on the following places:
> tmp/work/armv7a-poky-linux-gnueabi/libxmlpcp-0.1.0-r0/image/usr/lib
> tmp/sysroots/armv7a-poky-linux-gnueabi/usr/lib
> libxmlpcp-dbg_0.1.0-r0_armv7a.ipk and libxmlpcp-dev_0.1.0-r0_armv7a.ipk in the tmp/deploy/ipk/armv7a folder.
>
> I only get a "strip" error, can this be the reason it isn't included in the rootfs?
> ERROR: runstrip: ''arm-poky-linux-gnueabi-strip' --remove-section=.comment --remove-section=.note --strip-unneeded '/home/gerard/green-3.3/build/tmp/work/armv7a-poky-linux-gnueabi/libxmlpcp-0.1.0-r0/package/usr/lib/libxmlpcp.so'' strip command failed
It could very well be. Can you run file or readelf -e over libxmlpcp.so
and see if it is for ARM architecture ?
-Khem
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: compile application header file missing
2011-03-17 7:52 ` Khem Raj
@ 2011-03-17 8:00 ` Gerard van den Bosch
2011-03-17 8:22 ` Gerard van den Bosch
0 siblings, 1 reply; 9+ messages in thread
From: Gerard van den Bosch @ 2011-03-17 8:00 UTC (permalink / raw)
To: Richard Purdie, poky
On 03/17/2011 08:52 AM, Khem Raj wrote:
>> DESCRIPTION = "libxmlpcp"
>> SECTION = "libs"
>> DEPENDS = "openslp libxml2"
>> LICENSE = "LGPL"
>>
>> SRC_URI = "file://libxmlpcp.tar.gz"
>>
>> EXTRA_OEMAKE = "'CFLAGS=${CFLAGS} -fPIC -c -I${OPIEDIR}${includedir}/libxml2' 'LDFLAGS=${LDFLAGS} -shared -lxml2 -lslp'"
>>
>> do_install() {
>> install -d ${D}${libdir}
>> install -d ${D}${includedir}
>> oe_runmake 'INSTALLHEADERDIR=${D}${includedir}' 'INSTALLLIBDIR=${D}${libdir}' \
>> install
>> }
>>
>> But when build is done I can not find the lib in the actual rootfs, looking at the date the rootfs is being regenerated.
>>
>> The lib file exists in the build tree on the following places:
>> tmp/work/armv7a-poky-linux-gnueabi/libxmlpcp-0.1.0-r0/image/usr/lib
>> tmp/sysroots/armv7a-poky-linux-gnueabi/usr/lib
>> libxmlpcp-dbg_0.1.0-r0_armv7a.ipk and libxmlpcp-dev_0.1.0-r0_armv7a.ipk in the tmp/deploy/ipk/armv7a folder.
>>
>> I only get a "strip" error, can this be the reason it isn't included in the rootfs?
>> ERROR: runstrip: ''arm-poky-linux-gnueabi-strip' --remove-section=.comment --remove-section=.note --strip-unneeded '/home/gerard/green-3.3/build/tmp/work/armv7a-poky-linux-gnueabi/libxmlpcp-0.1.0-r0/package/usr/lib/libxmlpcp.so'' strip command failed
> It could very well be. Can you run file or readelf -e over libxmlpcp.so
> and see if it is for ARM architecture ?
>
> -Khem
This gives me the following ELF header:
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x12f0
Start of program headers: 52 (bytes into file)
Start of section headers: 29436 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 6
Size of section headers: 40 (bytes)
Number of section headers: 37
Section header string table index: 34
If I process the 'file' command it gives me:
libxmlpcp.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
Ok thus there is the problem, it isn't ARM architecture.
Regards,
Gerard
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: compile application header file missing
2011-03-17 8:00 ` Gerard van den Bosch
@ 2011-03-17 8:22 ` Gerard van den Bosch
2011-03-17 13:54 ` Gerard van den Bosch
0 siblings, 1 reply; 9+ messages in thread
From: Gerard van den Bosch @ 2011-03-17 8:22 UTC (permalink / raw)
To: poky
On 03/17/2011 09:00 AM, Gerard van den Bosch wrote:
> On 03/17/2011 08:52 AM, Khem Raj wrote:
>>> DESCRIPTION = "libxmlpcp"
>>> SECTION = "libs"
>>> DEPENDS = "openslp libxml2"
>>> LICENSE = "LGPL"
>>>
>>> SRC_URI = "file://libxmlpcp.tar.gz"
>>>
>>> EXTRA_OEMAKE = "'CFLAGS=${CFLAGS} -fPIC -c
>>> -I${OPIEDIR}${includedir}/libxml2' 'LDFLAGS=${LDFLAGS} -shared
>>> -lxml2 -lslp'"
>>>
>>> do_install() {
>>> install -d ${D}${libdir}
>>> install -d ${D}${includedir}
>>> oe_runmake 'INSTALLHEADERDIR=${D}${includedir}'
>>> 'INSTALLLIBDIR=${D}${libdir}' \
>>> install
>>> }
>>>
>>> But when build is done I can not find the lib in the actual rootfs,
>>> looking at the date the rootfs is being regenerated.
>>>
>>> The lib file exists in the build tree on the following places:
>>> tmp/work/armv7a-poky-linux-gnueabi/libxmlpcp-0.1.0-r0/image/usr/lib
>>> tmp/sysroots/armv7a-poky-linux-gnueabi/usr/lib
>>> libxmlpcp-dbg_0.1.0-r0_armv7a.ipk and
>>> libxmlpcp-dev_0.1.0-r0_armv7a.ipk in the tmp/deploy/ipk/armv7a folder.
>>>
>>> I only get a "strip" error, can this be the reason it isn't included
>>> in the rootfs?
>>> ERROR: runstrip: ''arm-poky-linux-gnueabi-strip'
>>> --remove-section=.comment --remove-section=.note --strip-unneeded
>>> '/home/gerard/green-3.3/build/tmp/work/armv7a-poky-linux-gnueabi/libxmlpcp-0.1.0-r0/package/usr/lib/libxmlpcp.so''
>>> strip command failed
>> It could very well be. Can you run file or readelf -e over libxmlpcp.so
>> and see if it is for ARM architecture ?
>>
>> -Khem
>
> This gives me the following ELF header:
> ELF Header:
> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
> Class: ELF32
> Data: 2's complement, little endian
> Version: 1 (current)
> OS/ABI: UNIX - System V
> ABI Version: 0
> Type: DYN (Shared object file)
> Machine: Intel 80386
> Version: 0x1
> Entry point address: 0x12f0
> Start of program headers: 52 (bytes into file)
> Start of section headers: 29436 (bytes into file)
> Flags: 0x0
> Size of this header: 52 (bytes)
> Size of program headers: 32 (bytes)
> Number of program headers: 6
> Size of section headers: 40 (bytes)
> Number of section headers: 37
> Section header string table index: 34
>
> If I process the 'file' command it gives me:
> libxmlpcp.so: ELF 32-bit LSB shared object, Intel 80386, version 1
> (SYSV), dynamically linked, not stripped
>
> Ok thus there is the problem, it isn't ARM architecture.
>
> Regards,
> Gerard
>
>
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
Added CC=${CC} to the EXTRA_OEMAKE parameter and it now builds it as ARM lib.
The strip error is gone but file isn't stripped:libxmlpcp.so:
ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped
However strangely still missing it in the rootfs, but I will continue my search.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-03-17 13:54 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-15 10:57 compile application header file missing Gerard van den Bosch
2011-03-15 13:38 ` Richard Purdie
2011-03-15 15:03 ` Gerard van den Bosch
2011-03-16 16:08 ` Richard Purdie
2011-03-17 7:43 ` Gerard van den Bosch
2011-03-17 7:52 ` Khem Raj
2011-03-17 8:00 ` Gerard van den Bosch
2011-03-17 8:22 ` Gerard van den Bosch
2011-03-17 13:54 ` Gerard van den Bosch
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.