precompiled binary problem
Hello, I am using a RPI3 B+ and using openadk successfully with the linux os using 4.14.71 kernel from raspberry pi itself. Now I am trying to run “openvino R5” which is an intel library that is only available as a precompiled so file for raspbian 9. It works indeed on raspbian 9. But when I try to run their example demo file on my system, I get the error: # ./myriad_compile mksh: ./myriad_compile: not executable: 32-bit ELF file So now I want to debug that, but I’m out of ideas on how to proceed. You can find the package here: https://drive.google.com/open?id=1QQL343Svovi0ZQ0YewyiMdtt-m6TyHOc <https://drive.google.com/open?id=1QQL343Svovi0ZQ0YewyiMdtt-m6TyHOc> just unpack it in the “package” directory to try it out. So if you have any hints, I would really appreciate it. I’m using glibc 2.27, with gcc 7.3.0 compiler. Best regards, Tom,
Hi Tom, you can not run x86 or amd64 programs on the arm processor natively. You have to compile it for arm or you will not be able to run it on the RPI. Regards Martin Am 28.02.19 um 09:19 schrieb Tom Deblauwe:
Hello,
I am using a RPI3 B+ and using openadk successfully with the linux os using 4.14.71 kernel from raspberry pi itself. Now I am trying to run “openvino R5” which is an intel library that is only available as a precompiled so file for raspbian 9. It works indeed on raspbian 9.
But when I try to run their example demo file on my system, I get the error:
# ./myriad_compile mksh: ./myriad_compile: not executable: 32-bit ELF file
So now I want to debug that, but I’m out of ideas on how to proceed.
You can find the package here: https://drive.google.com/open?id=1QQL343Svovi0ZQ0YewyiMdtt-m6TyHOc just unpack it in the “package” directory to try it out.
So if you have any hints, I would really appreciate it.
I’m using glibc 2.27, with gcc 7.3.0 compiler.
Best regards, Tom,
_______________________________________________ dev mailing list dev@openadk.org https://mailman.openadk.org/cgi-bin/mailman/listinfo/dev
The archive contains ARM architecture files, as Tom mentioned. $ find . | xargs -L1 file .: directory ./.DS_Store: Apple Desktop Services Store ./files: directory ./files/.DS_Store: Apple Desktop Services Store ./files/libcpu_extension.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=bca52678a3100264f856ae981378023a33ecf6c4, stripped ./files/libHeteroPlugin.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=0d135cf910571782588cae5a812358162dced8d2, stripped ./files/libinference_engine.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=7a8c112a128ff2bb84430c17323e774cc17ff8d9, stripped ./files/libmyriadPlugin.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=1106b14db6778bc4530768c40273a5f17af7cb7d, stripped ./files/mvnc: directory ./files/mvnc/MvNCAPI-ma2450.mvcmd: data ./files/mvnc/MvNCAPI-ma2480.mvcmd: data ./files/myriad_compile: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=4d7256a454df4b9a224ab5d9c3411d8741cd91d2, stripped So there must be a different explanation. Can you verify that the file is properly transferred? Because for me on my PI3 I can run the program to a point where it gives me ./myriad_compile: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory which is a later linker loading error. Cheers, Diez
On 28. Feb 2019, at 12:17, Martin Thomas <mtadk@hamtam.de> wrote:
Hi Tom,
you can not run x86 or amd64 programs on the arm processor natively. You have to compile it for arm or you will not be able to run it on the RPI.
Regards
Martin
Am 28.02.19 um 09:19 schrieb Tom Deblauwe:
Hello,
I am using a RPI3 B+ and using openadk successfully with the linux os using 4.14.71 kernel from raspberry pi itself. Now I am trying to run “openvino R5” which is an intel library that is only available as a precompiled so file for raspbian 9. It works indeed on raspbian 9.
But when I try to run their example demo file on my system, I get the error:
# ./myriad_compile mksh: ./myriad_compile: not executable: 32-bit ELF file
So now I want to debug that, but I’m out of ideas on how to proceed.
You can find the package here: https://drive.google.com/open?id=1QQL343Svovi0ZQ0YewyiMdtt-m6TyHOc <https://drive.google.com/open?id=1QQL343Svovi0ZQ0YewyiMdtt-m6TyHOc> just unpack it in the “package” directory to try it out.
So if you have any hints, I would really appreciate it.
I’m using glibc 2.27, with gcc 7.3.0 compiler.
Best regards, Tom,
_______________________________________________ dev mailing list dev@openadk.org <mailto:dev@openadk.org> https://mailman.openadk.org/cgi-bin/mailman/listinfo/dev <https://mailman.openadk.org/cgi-bin/mailman/listinfo/dev>
dev mailing list dev@openadk.org https://mailman.openadk.org/cgi-bin/mailman/listinfo/dev
Hi! Thanks for checking it out. Yes, the transfer is ok, I verified it with md5sum. So under “c library configuration” I am using “arm” as the “instruction set”. Now I changed it to “thumb” and I am now trying to make that boot again. But as a quick test, I uploaded one of these binaries from the new thumb-based root directory to my old OS and I get the exact same error… and I also uploaded that very same file to the official raspbian 9 OS and there it runs without problems. Can you maybe tell if you are also using “thumb” or are using “arm” ? May I ask, what commit and tasks are you using for your test you just did? Best regards, Tom,
On 28 Feb 2019, at 12:32, Diez B. Roggisch <deets@web.de> wrote:
The archive contains ARM architecture files, as Tom mentioned.
$ find . | xargs -L1 file .: directory ./.DS_Store: Apple Desktop Services Store ./files: directory ./files/.DS_Store: Apple Desktop Services Store ./files/libcpu_extension.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=bca52678a3100264f856ae981378023a33ecf6c4, stripped ./files/libHeteroPlugin.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=0d135cf910571782588cae5a812358162dced8d2, stripped ./files/libinference_engine.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=7a8c112a128ff2bb84430c17323e774cc17ff8d9, stripped ./files/libmyriadPlugin.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=1106b14db6778bc4530768c40273a5f17af7cb7d, stripped ./files/mvnc: directory ./files/mvnc/MvNCAPI-ma2450.mvcmd: data ./files/mvnc/MvNCAPI-ma2480.mvcmd: data ./files/myriad_compile: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=4d7256a454df4b9a224ab5d9c3411d8741cd91d2, stripped
So there must be a different explanation.
Can you verify that the file is properly transferred? Because for me on my PI3 I can run the program to a point where it gives me
./myriad_compile: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
which is a later linker loading error.
Cheers,
Diez
On 28. Feb 2019, at 12:17, Martin Thomas <mtadk@hamtam.de <mailto:mtadk@hamtam.de>> wrote:
Hi Tom,
you can not run x86 or amd64 programs on the arm processor natively. You have to compile it for arm or you will not be able to run it on the RPI.
Regards
Martin
Am 28.02.19 um 09:19 schrieb Tom Deblauwe:
Hello,
I am using a RPI3 B+ and using openadk successfully with the linux os using 4.14.71 kernel from raspberry pi itself. Now I am trying to run “openvino R5” which is an intel library that is only available as a precompiled so file for raspbian 9. It works indeed on raspbian 9.
But when I try to run their example demo file on my system, I get the error:
# ./myriad_compile mksh: ./myriad_compile: not executable: 32-bit ELF file
So now I want to debug that, but I’m out of ideas on how to proceed.
You can find the package here: https://drive.google.com/open?id=1QQL343Svovi0ZQ0YewyiMdtt-m6TyHOc <https://drive.google.com/open?id=1QQL343Svovi0ZQ0YewyiMdtt-m6TyHOc> just unpack it in the “package” directory to try it out.
So if you have any hints, I would really appreciate it.
I’m using glibc 2.27, with gcc 7.3.0 compiler.
Best regards, Tom,
_______________________________________________ dev mailing list dev@openadk.org <mailto:dev@openadk.org> https://mailman.openadk.org/cgi-bin/mailman/listinfo/dev <https://mailman.openadk.org/cgi-bin/mailman/listinfo/dev>
dev mailing list dev@openadk.org <mailto:dev@openadk.org> https://mailman.openadk.org/cgi-bin/mailman/listinfo/dev
_______________________________________________ dev mailing list dev@openadk.org https://mailman.openadk.org/cgi-bin/mailman/listinfo/dev
In the meantime, I confirmed that this is the problem indeed! I have to enable “thumb” and then it runs... Only thing I encountered is that under “linux/config/Config.in.instructions” there is a line like this: select ADK_LINUX_KERNEL_THUMB2_KERNEL if ADK_TARGET_OS_LINUX but I had to disable it because my OS would not boot with the thumb2 instructions. I also compared with raspbian 9 it’s kernel config and they also do not enable that option. Thanks everyone! Best regards, Tom,
On 28 Feb 2019, at 12:41, Tom Deblauwe <deblauwetom@gmail.com> wrote:
Hi!
Thanks for checking it out.
Yes, the transfer is ok, I verified it with md5sum.
So under “c library configuration” I am using “arm” as the “instruction set”. Now I changed it to “thumb” and I am now trying to make that boot again. But as a quick test, I uploaded one of these binaries from the new thumb-based root directory to my old OS and I get the exact same error… and I also uploaded that very same file to the official raspbian 9 OS and there it runs without problems.
Can you maybe tell if you are also using “thumb” or are using “arm” ?
May I ask, what commit and tasks are you using for your test you just did?
Best regards, Tom,
On 28 Feb 2019, at 12:32, Diez B. Roggisch <deets@web.de <mailto:deets@web.de>> wrote:
The archive contains ARM architecture files, as Tom mentioned.
$ find . | xargs -L1 file .: directory ./.DS_Store: Apple Desktop Services Store ./files: directory ./files/.DS_Store: Apple Desktop Services Store ./files/libcpu_extension.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=bca52678a3100264f856ae981378023a33ecf6c4, stripped ./files/libHeteroPlugin.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=0d135cf910571782588cae5a812358162dced8d2, stripped ./files/libinference_engine.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=7a8c112a128ff2bb84430c17323e774cc17ff8d9, stripped ./files/libmyriadPlugin.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=1106b14db6778bc4530768c40273a5f17af7cb7d, stripped ./files/mvnc: directory ./files/mvnc/MvNCAPI-ma2450.mvcmd: data ./files/mvnc/MvNCAPI-ma2480.mvcmd: data ./files/myriad_compile: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=4d7256a454df4b9a224ab5d9c3411d8741cd91d2, stripped
So there must be a different explanation.
Can you verify that the file is properly transferred? Because for me on my PI3 I can run the program to a point where it gives me
./myriad_compile: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
which is a later linker loading error.
Cheers,
Diez
On 28. Feb 2019, at 12:17, Martin Thomas <mtadk@hamtam.de <mailto:mtadk@hamtam.de>> wrote:
Hi Tom,
you can not run x86 or amd64 programs on the arm processor natively. You have to compile it for arm or you will not be able to run it on the RPI.
Regards
Martin
Am 28.02.19 um 09:19 schrieb Tom Deblauwe:
Hello,
I am using a RPI3 B+ and using openadk successfully with the linux os using 4.14.71 kernel from raspberry pi itself. Now I am trying to run “openvino R5” which is an intel library that is only available as a precompiled so file for raspbian 9. It works indeed on raspbian 9.
But when I try to run their example demo file on my system, I get the error:
# ./myriad_compile mksh: ./myriad_compile: not executable: 32-bit ELF file
So now I want to debug that, but I’m out of ideas on how to proceed.
You can find the package here: https://drive.google.com/open?id=1QQL343Svovi0ZQ0YewyiMdtt-m6TyHOc <https://drive.google.com/open?id=1QQL343Svovi0ZQ0YewyiMdtt-m6TyHOc> just unpack it in the “package” directory to try it out.
So if you have any hints, I would really appreciate it.
I’m using glibc 2.27, with gcc 7.3.0 compiler.
Best regards, Tom,
_______________________________________________ dev mailing list dev@openadk.org <mailto:dev@openadk.org> https://mailman.openadk.org/cgi-bin/mailman/listinfo/dev <https://mailman.openadk.org/cgi-bin/mailman/listinfo/dev>
dev mailing list dev@openadk.org <mailto:dev@openadk.org> https://mailman.openadk.org/cgi-bin/mailman/listinfo/dev <https://mailman.openadk.org/cgi-bin/mailman/listinfo/dev>
_______________________________________________ dev mailing list dev@openadk.org <mailto:dev@openadk.org> https://mailman.openadk.org/cgi-bin/mailman/listinfo/dev
Hi all When I try to build a new appliance for arm, raspberry pi 3 model b+ (just these two things selected in menuconfig, rev. f8d0864c18907ea4e21d0657b34869cda66dd452), I get some errors like this: tmp/cckyIFbk.s: Assembler messages: /tmp/cckyIFbk.s:67: Error: selected processor does not support `dmb ish' in ARM Looks like something goes wrong with some flags. make.log: https://mega.nz/#!BxJnwQgR!-7Gkl_WuBg5L_0CFNf8Jp43Fqduu2siI47gvocJIXys I get no problem when choosing aarch64: https://mega.nz/#!RtZzXagR!QIvUgjipkzg_y32zReKYjRPCKHfK7dy2bcGjw1vR4RE Does somebody know if something changed in the definitions of these flags, maybe in a newer version of GCC, since that changed recently? Don't really know where to start looking... Cheers Oliver
Hi again It looks like this is a problem with gcc 8. The kernel won't build, neither with uglibc-ng nor with glibc selected. Also not with gcc version git. gcc 7 builds fine and boots, (arm, raspberry pi 3 model b+, new appliance, kernel and bootloader updated as per my patch). Build is possible on gcc 8 when choosing aarch64. Unfortunately, this does not boot (rainbow screen, can't ping). Any ideas how to make gcc 8 work? Oliver On 18.03.19 21:36, lich000king wrote:
Hi all
When I try to build a new appliance for arm, raspberry pi 3 model b+ (just these two things selected in menuconfig, rev. f8d0864c18907ea4e21d0657b34869cda66dd452),?? I get some errors like this:
tmp/cckyIFbk.s: Assembler messages: /tmp/cckyIFbk.s:67: Error: selected processor does not support `dmb ish' in ARM
Looks like something goes wrong with some flags.
make.log:
https://mega.nz/#!BxJnwQgR!-7Gkl_WuBg5L_0CFNf8Jp43Fqduu2siI47gvocJIXys
I get no problem when choosing aarch64:
https://mega.nz/#!RtZzXagR!QIvUgjipkzg_y32zReKYjRPCKHfK7dy2bcGjw1vR4RE
Does somebody know if something changed in the definitions of these flags, maybe in a newer version of GCC, since that changed recently?
Don't really know where to start looking...
Cheers
Oliver
Hi Sounds a lot like this: https://www.spinics.net/lists/arm-kernel/msg712490.html and the solution is there as well. But I don't know where to put this flag in adk. And I don't know how to fix this otherwise. Updating the kernel to 5.0.7, glibc to 2.29, mpfr to 4.0.2 and llvm to 7.0.1 did not help... The patch below makes it build, but trying to boot gives a kernel panic, so I guess this is not the right way. Can anyone help? Thanks Oliver a7e51dedd4/fix-arch.patch --- linux-1026f584d33f27cf0101590a41d2d8a7e51dedd4/arch/arm/Makefile.orig 2019-04-09 18:02:25.564918359 +0200 +++ linux-1026f584d33f27cf0101590a41d2d8a7e51dedd4/arch/arm/Makefile 2019-04-09 18:13:01.159228340 +0200 @@ -64,7 +64,7 @@ # macro, but instead defines a whole series of macros which makes # testing for a specific architecture or later rather impossible. arch-$(CONFIG_CPU_32v7M) =-D__LINUX_ARM_ARCH__=7 -march=armv7-m -Wa,-march=armv7-m -arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a) +arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 -march=armv7-a arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6) # Only override the compiler option if ARMv6. The ARMv6K extensions are # always available in ARMv7 On 07.04.19 19:18, lich000king wrote:
Hi again
It looks like this is a problem with gcc 8. The kernel won't build, neither with uglibc-ng nor with glibc selected. Also not with gcc version git.
gcc 7 builds fine and boots, (arm, raspberry pi 3 model b+, new appliance, kernel and bootloader updated as per my patch).
Build is possible on gcc 8 when choosing aarch64. Unfortunately, this does not boot (rainbow screen, can't ping).
Any ideas how to make gcc 8 work?
Oliver
On 18.03.19 21:36, lich000king wrote:
Hi all
When I try to build a new appliance for arm, raspberry pi 3 model b+ (just these two things selected in menuconfig, rev. f8d0864c18907ea4e21d0657b34869cda66dd452), I get some errors like this:
tmp/cckyIFbk.s: Assembler messages: /tmp/cckyIFbk.s:67: Error: selected processor does not support `dmb ish' in ARM
Looks like something goes wrong with some flags.
make.log:
https://mega.nz/#!BxJnwQgR!-7Gkl_WuBg5L_0CFNf8Jp43Fqduu2siI47gvocJIXys
I get no problem when choosing aarch64:
https://mega.nz/#!RtZzXagR!QIvUgjipkzg_y32zReKYjRPCKHfK7dy2bcGjw1vR4RE
Does somebody know if something changed in the definitions of these flags, maybe in a newer version of GCC, since that changed recently?
Don't really know where to start looking...
Cheers
Oliver
Ok, got it. However, the below patch also gives the attached kernel panic. Also with adk revision f8d0864c18907ea4e21d0657b34869cda66dd452 that does boot when using gcc 7... --- linux-a2092141807514666a273971cc8fa9e80f14439f/arch/arm/Makefile.orig 2019-04-13 19:01:23.129152269 +0200 +++ linux-a2092141807514666a273971cc8fa9e80f14439f/arch/arm/Makefile 2019-04-13 19:03:51.038118795 +0200 @@ -29,6 +29,11 @@ # Never generate .eh_frame KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm) +# kernel always built with soft float, define it early so it participates in +# cc-option evaluation for arch and tune settings +KBUILD_CFLAGS += -msoft-float + + # This should work on most of the modern platforms KBUILD_DEFCONFIG := multi_v7_defconfig @@ -130,7 +135,7 @@ endif # Need -Uarm for gcc < 3.x -KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm +KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -Uarm KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float CHECKFLAGS += -D__arm__ -m32 On 11.04.19 21:04, lich000king wrote:
Hi
Sounds a lot like this:
https://www.spinics.net/lists/arm-kernel/msg712490.html
and the solution is there as well. But I don't know where to put this flag in adk.
And I don't know how to fix this otherwise. Updating the kernel to 5.0.7, glibc to 2.29, mpfr to 4.0.2 and llvm to 7.0.1 did not help...
The patch below makes it build, but trying to boot gives a kernel panic, so I guess this is not the right way.
Can anyone help?
Thanks
Oliver
a7e51dedd4/fix-arch.patch --- linux-1026f584d33f27cf0101590a41d2d8a7e51dedd4/arch/arm/Makefile.orig 2019-04-09 18:02:25.564918359 +0200 +++ linux-1026f584d33f27cf0101590a41d2d8a7e51dedd4/arch/arm/Makefile 2019-04-09 18:13:01.159228340 +0200 @@ -64,7 +64,7 @@ # macro, but instead defines a whole series of macros which makes # testing for a specific architecture or later rather impossible. arch-$(CONFIG_CPU_32v7M) =-D__LINUX_ARM_ARCH__=7 -march=armv7-m -Wa,-march=armv7-m -arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a) +arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 -march=armv7-a arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6) # Only override the compiler option if ARMv6. The ARMv6K extensions are # always available in ARMv7
On 07.04.19 19:18, lich000king wrote:
Hi again
It looks like this is a problem with gcc 8. The kernel won't build, neither with uglibc-ng nor with glibc selected. Also not with gcc version git.
gcc 7 builds fine and boots, (arm, raspberry pi 3 model b+, new appliance, kernel and bootloader updated as per my patch).
Build is possible on gcc 8 when choosing aarch64. Unfortunately, this does not boot (rainbow screen, can't ping).
Any ideas how to make gcc 8 work?
Oliver
On 18.03.19 21:36, lich000king wrote:
Hi all
When I try to build a new appliance for arm, raspberry pi 3 model b+ (just these two things selected in menuconfig, rev. f8d0864c18907ea4e21d0657b34869cda66dd452), I get some errors like this:
tmp/cckyIFbk.s: Assembler messages: /tmp/cckyIFbk.s:67: Error: selected processor does not support `dmb ish' in ARM
Looks like something goes wrong with some flags.
make.log:
https://mega.nz/#!BxJnwQgR!-7Gkl_WuBg5L_0CFNf8Jp43Fqduu2siI47gvocJIXys
I get no problem when choosing aarch64:
https://mega.nz/#!RtZzXagR!QIvUgjipkzg_y32zReKYjRPCKHfK7dy2bcGjw1vR4RE
Does somebody know if something changed in the definitions of these flags, maybe in a newer version of GCC, since that changed recently?
Don't really know where to start looking...
Cheers
Oliver
participants (4)
-
Diez B. Roggisch -
lich000king -
Martin Thomas -
Tom Deblauwe