Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2013.12.2 released
Hi Michael Am Freitag, 26. September 2014, 08:46:21 schrieb Michael Olbrich: On Wed, Sep 24, 2014 at 03:43:10PM +0200, Tim Sander wrote: I'm happy to announce that I've just released OSELAS.Toolchain-2013.12.2. This is a bugfix-only release. The relevant changes since 2013.12.1 are: - The toolchains can now be built with make 4.0 - Some toolchains did not optimize for the correct CPU. The code works but might be slower. This is fixed now. - All security relevant fixes mentioned in the glibc 2.19 changelog have been added for glibc 2.18 based toolchains. - All generated toolchain archives are now XZ comressed. While i have used this toolchain arm-v7a-linux-gnueabihf with an Xilinx Zynx compiling nearly the same Project with a different Kernelconfig /DTB for Altera SOC fails with this toolchain !?! The kernel boots but on mounting the rootfs it fails to execute any binary? Is the dynamic linker (whatever /lib/ld-linux-armhf.so.3 points to) executable? Do you have a working system? Boot it and try to chroot into your new system. You get better error messages that way. Ok i have now setup booted into the environment compiled with OSELAS.Toolchain-2012.12.1/arm-cortexa9-linux-gnueabihf, mounted the other system via nfs and tried to start any executable: /mnt/bin/busybox: line 1: syntax error: unexpected word (expecting )) (thats with OSELAS.Toolchain-2013.12.2/arm-v7a-linux-gnueabihf on Altera SOC) I have taken a look at both busyboxes and have run them through readelf -e (attached). The only difference which sprung to my eye was the hardfloat support, which i don't understand as both toolchains should be hardfloat toolchains. Starting the binary with strace gives: execve(mnt/bin/busybox, [mnt/bin/busybox], [/* 11 vars */]) = -1 ENOEXEC (Exec format error) write(2, strace: exec: Exec format error\n, 32strace: exec: Exec format error ) = 32 exit_group(1) = ? +++ exited with 1 +++ So i have an execution error and the shell error seems to be the shell fallback from the kernel. Another thing which caught my attention was the fact that: objdump -d bin/busybox |grep UNDEFINED |wc -l is 364 for the old and 13478 for the new toolchain. Best regards TimELF-Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Klasse:ELF32 Daten: 2er-Komplement, Little-Endian Version: 1 (current) OS/ABI:UNIX - System V ABI-Version: 0 Typ: EXEC (ausführbare Datei) Maschine: ARM Version: 0x1 Einstiegspunktadresse: 0x10010 Beginn der Programm-Header: 52 (Bytes in Datei) Beginn der Sektions-header: 460812 (Bytes in Datei) Flags: 0x502, has entry point, Version5 EABI Größe dieses Headers: 52 (Byte) Größe der Programm-Header: 32 (Byte) Number of program headers: 8 Größe der Sektions-Header: 40 (bytes) Anzahl der Sektions-Header:28 Sektions-Header Stringtabellen-Index: 27 Sektions-Header: [Nr] Name Typ Adr OffGröße ES Flg Lk Inf Ar [ 0] NULL 00 00 00 0 0 0 [ 1] .interp PROGBITS8134 000134 19 00 A 0 0 1 [ 2] .note.ABI-tag NOTE8150 000150 20 00 A 0 0 4 [ 3] .hash HASH8170 000170 0008cc 04 A 4 0 4 [ 4] .dynsym DYNSYM 8a3c 000a3c 0012a0 10 A 5 1 4 [ 5] .dynstr STRTAB 9cdc 001cdc 00097c 00 A 0 0 1 [ 6] .gnu.version VERSYM a658 002658 000254 02 A 4 0 2 [ 7] .gnu.version_rVERNEED a8ac 0028ac 20 00 A 5 1 4 [ 8] .rel.dyn REL a8cc 0028cc 48 08 A 4 0 4 [ 9] .rel.plt REL a914 002914 0008e8 08 A 4 11 4 [10] .init PROGBITSb1fc 0031fc 0c 00 AX 0 0 4 [11] .plt PROGBITSb208 003208 000d70 04 AX 0 0 4 [12] .text PROGBITSbf78 003f78 05c610 00 AX 0 0 8 [13] .fini PROGBITS00068588 060588 08 00 AX 0 0 4 [14] .rodata PROGBITS00068590 060590 00f0f4 00 A 0 0 4 [15] .ARM.extabPROGBITS00077684 06f684 30 00 A 0 0 4 [16] .ARM.exidxARM_EXIDX 000776b4 06f6b4 d8 00 AL 12 0 4 [17] .eh_frame PROGBITS0007778c 06f78c 04 00 A 0 0 4 [18] .init_array INIT_ARRAY 00078000 07 04 00 WA 0 0 4 [19] .fini_array FINI_ARRAY 00078004 070004 04 00 WA 0
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2013.12.2 released
On Mon, Sep 29, 2014 at 03:56:40PM +0200, Tim Sander wrote: Am Freitag, 26. September 2014, 08:46:21 schrieb Michael Olbrich: On Wed, Sep 24, 2014 at 03:43:10PM +0200, Tim Sander wrote: I'm happy to announce that I've just released OSELAS.Toolchain-2013.12.2. This is a bugfix-only release. The relevant changes since 2013.12.1 are: - The toolchains can now be built with make 4.0 - Some toolchains did not optimize for the correct CPU. The code works but might be slower. This is fixed now. - All security relevant fixes mentioned in the glibc 2.19 changelog have been added for glibc 2.18 based toolchains. - All generated toolchain archives are now XZ comressed. While i have used this toolchain arm-v7a-linux-gnueabihf with an Xilinx Zynx compiling nearly the same Project with a different Kernelconfig /DTB for Altera SOC fails with this toolchain !?! The kernel boots but on mounting the rootfs it fails to execute any binary? Is the dynamic linker (whatever /lib/ld-linux-armhf.so.3 points to) executable? Do you have a working system? Boot it and try to chroot into your new system. You get better error messages that way. Ok i have now setup booted into the environment compiled with OSELAS.Toolchain-2012.12.1/arm-cortexa9-linux-gnueabihf, mounted the other system via nfs and tried to start any executable: Carefull: you need to chroot into the new root, otherwise you'll use the wrong linker (/lib/ld-linux-armhf.so.3). Did you do this? /mnt/bin/busybox: line 1: syntax error: unexpected word (expecting )) (thats with OSELAS.Toolchain-2013.12.2/arm-v7a-linux-gnueabihf on Altera SOC) I have taken a look at both busyboxes and have run them through readelf -e (attached). The only difference which sprung to my eye was the hardfloat support, which i don't understand as both toolchains should be hardfloat toolchains. They are: The linker is /lib/ld-linux-armhf.so.3 for both. I'm not sure why the old binary is missing the hf flag. Starting the binary with strace gives: execve(mnt/bin/busybox, [mnt/bin/busybox], [/* 11 vars */]) = -1 ENOEXEC (Exec format error) write(2, strace: exec: Exec format error\n, 32strace: exec: Exec format error ) = 32 exit_group(1) = ? +++ exited with 1 +++ So i have an execution error and the shell error seems to be the shell fallback from the kernel. Another thing which caught my attention was the fact that: objdump -d bin/busybox |grep UNDEFINED |wc -l is 364 for the old and 13478 for the new toolchain. Try using objdump from the toolchain. Do you still get these results? Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2013.12.2 released
Hi Michael Am Freitag, 26. September 2014, 08:46:21 schrieb Michael Olbrich: On Wed, Sep 24, 2014 at 03:43:10PM +0200, Tim Sander wrote: I'm happy to announce that I've just released OSELAS.Toolchain-2013.12.2. This is a bugfix-only release. The relevant changes since 2013.12.1 are: - The toolchains can now be built with make 4.0 - Some toolchains did not optimize for the correct CPU. The code works but might be slower. This is fixed now. - All security relevant fixes mentioned in the glibc 2.19 changelog have been added for glibc 2.18 based toolchains. - All generated toolchain archives are now XZ comressed. While i have used this toolchain arm-v7a-linux-gnueabihf with an Xilinx Zynx compiling nearly the same Project with a different Kernelconfig /DTB for Altera SOC fails with this toolchain !?! The kernel boots but on mounting the rootfs it fails to execute any binary? Is the dynamic linker (whatever /lib/ld-linux-armhf.so.3 points to) executable? Do you have a working system? Boot it and try to chroot into your new system. You get better error messages that way. Ok i have now setup booted into the environment compiled with OSELAS.Toolchain-2012.12.1/arm-cortexa9-linux-gnueabihf, mounted the other system via nfs and tried to start any executable: /mnt/bin/busybox: line 1: syntax error: unexpected word (expecting )) (thats with OSELAS.Toolchain-2013.12.2/arm-v7a-linux-gnueabihf on Altera SOC) I have taken a look at both busyboxes and have run them through readelf -e (attached). The only difference which sprung to my eye was the hardfloat support, which i don't understand as both toolchains should be hardfloat toolchains. Starting the binary with strace gives: execve(mnt/bin/busybox, [mnt/bin/busybox], [/* 11 vars */]) = -1 ENOEXEC (Exec format error) write(2, strace: exec: Exec format error\n, 32strace: exec: Exec format error ) = 32 exit_group(1) = ? +++ exited with 1 +++ So i have an execution error and the shell error seems to be the shell fallback from the kernel. Another thing which caught my attention was the fact that: objdump -d bin/busybox |grep UNDEFINED |wc -l is 364 for the old and 13478 for the new toolchain. Best regards TimELF-Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Klasse:ELF32 Daten: 2er-Komplement, Little-Endian Version: 1 (current) OS/ABI:UNIX - System V ABI-Version: 0 Typ: EXEC (ausführbare Datei) Maschine: ARM Version: 0x1 Einstiegspunktadresse: 0x10010 Beginn der Programm-Header: 52 (Bytes in Datei) Beginn der Sektions-header: 460812 (Bytes in Datei) Flags: 0x502, has entry point, Version5 EABI Größe dieses Headers: 52 (Byte) Größe der Programm-Header: 32 (Byte) Number of program headers: 8 Größe der Sektions-Header: 40 (bytes) Anzahl der Sektions-Header:28 Sektions-Header Stringtabellen-Index: 27 Sektions-Header: [Nr] Name Typ Adr OffGröße ES Flg Lk Inf Ar [ 0] NULL 00 00 00 0 0 0 [ 1] .interp PROGBITS8134 000134 19 00 A 0 0 1 [ 2] .note.ABI-tag NOTE8150 000150 20 00 A 0 0 4 [ 3] .hash HASH8170 000170 0008cc 04 A 4 0 4 [ 4] .dynsym DYNSYM 8a3c 000a3c 0012a0 10 A 5 1 4 [ 5] .dynstr STRTAB 9cdc 001cdc 00097c 00 A 0 0 1 [ 6] .gnu.version VERSYM a658 002658 000254 02 A 4 0 2 [ 7] .gnu.version_rVERNEED a8ac 0028ac 20 00 A 5 1 4 [ 8] .rel.dyn REL a8cc 0028cc 48 08 A 4 0 4 [ 9] .rel.plt REL a914 002914 0008e8 08 A 4 11 4 [10] .init PROGBITSb1fc 0031fc 0c 00 AX 0 0 4 [11] .plt PROGBITSb208 003208 000d70 04 AX 0 0 4 [12] .text PROGBITSbf78 003f78 05c610 00 AX 0 0 8 [13] .fini PROGBITS00068588 060588 08 00 AX 0 0 4 [14] .rodata PROGBITS00068590 060590 00f0f4 00 A 0 0 4 [15] .ARM.extabPROGBITS00077684 06f684 30 00 A 0 0 4 [16] .ARM.exidxARM_EXIDX 000776b4 06f6b4 d8 00 AL 12 0 4 [17] .eh_frame PROGBITS0007778c 06f78c 04 00 A 0 0 4 [18] .init_array INIT_ARRAY 00078000 07 04 00 WA 0 0 4 [19] .fini_array FINI_ARRAY 00078004 070004 04 00 WA 0
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2013.12.2 released
Hi Uwe Thanks for your reply. It sounds it could get more involved, if yes we should set up some support for this via private mail, as i am wearing my business hat. Am Mittwoch, 24. September 2014, 20:01:54 schrieb Uwe Kleine-König: On Wed, Sep 24, 2014 at 03:43:10PM +0200, Tim Sander wrote: Hi I'm happy to announce that I've just released OSELAS.Toolchain-2013.12.2. This is a bugfix-only release. The relevant changes since 2013.12.1 are: - The toolchains can now be built with make 4.0 - Some toolchains did not optimize for the correct CPU. The code works but might be slower. This is fixed now. - All security relevant fixes mentioned in the glibc 2.19 changelog have been added for glibc 2.18 based toolchains. - All generated toolchain archives are now XZ comressed. While i have used this toolchain arm-v7a-linux-gnueabihf with an Xilinx Zynx compiling nearly the same Project with a different Kernelconfig /DTB for Altera SOC fails with this toolchain !?! The kernel boots but on mounting the rootfs it fails to execute any binary? Compiling the same project with OSELAS.Toolchain-2012.12.1/arm-cortexa9-linux- gnueabihf/gcc-4.7.3-glibc-2.16.0-binutils-2.22-kernel-3.6-sanitized does work however. I have also tried setting: PTXCONF_TARGET_EXTRA_CFLAGS=-mcpu=cortex-a9 -mfpu=neon PTXCONF_TARGET_EXTRA_CXXFLAGS=-mcpu=cortex-a9 -mfpu=neon But it still fails on executing any binary. Without knowing details about the two toolchains in question, this might be an ABI-problem. Does your kernel have OABI_COMPAT=y? No its disabled, in the Xilinx Zynq (working) and the Altera SOC (not working) but CONFIG_AEABI=y . Did you try to run a 2013.12.1 userspace with a 2012.12.1-compiled kernel and vice versa? No, i was doing a ptxdist clean inbetween switching toolchains. So the whole project was only compiled with one compiler. That is, if ptxdist clean is working as expected. Best regards Tim -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2013.12.2 released
On Wed, Sep 24, 2014 at 03:43:10PM +0200, Tim Sander wrote: I'm happy to announce that I've just released OSELAS.Toolchain-2013.12.2. This is a bugfix-only release. The relevant changes since 2013.12.1 are: - The toolchains can now be built with make 4.0 - Some toolchains did not optimize for the correct CPU. The code works but might be slower. This is fixed now. - All security relevant fixes mentioned in the glibc 2.19 changelog have been added for glibc 2.18 based toolchains. - All generated toolchain archives are now XZ comressed. While i have used this toolchain arm-v7a-linux-gnueabihf with an Xilinx Zynx compiling nearly the same Project with a different Kernelconfig /DTB for Altera SOC fails with this toolchain !?! The kernel boots but on mounting the rootfs it fails to execute any binary? Is the dynamic linker (whatever /lib/ld-linux-armhf.so.3 points to) executable? Do you have a working system? Boot it and try to chroot into your new system. You get better error messages that way. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2013.12.2 released
Hi I'm happy to announce that I've just released OSELAS.Toolchain-2013.12.2. This is a bugfix-only release. The relevant changes since 2013.12.1 are: - The toolchains can now be built with make 4.0 - Some toolchains did not optimize for the correct CPU. The code works but might be slower. This is fixed now. - All security relevant fixes mentioned in the glibc 2.19 changelog have been added for glibc 2.18 based toolchains. - All generated toolchain archives are now XZ comressed. While i have used this toolchain arm-v7a-linux-gnueabihf with an Xilinx Zynx compiling nearly the same Project with a different Kernelconfig /DTB for Altera SOC fails with this toolchain !?! The kernel boots but on mounting the rootfs it fails to execute any binary? Compiling the same project with OSELAS.Toolchain-2012.12.1/arm-cortexa9-linux- gnueabihf/gcc-4.7.3-glibc-2.16.0-binutils-2.22-kernel-3.6-sanitized does work however. I have also tried setting: PTXCONF_TARGET_EXTRA_CFLAGS=-mcpu=cortex-a9 -mfpu=neon PTXCONF_TARGET_EXTRA_CXXFLAGS=-mcpu=cortex-a9 -mfpu=neon But it still fails on executing any binary. Best regards Tim -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2013.12.2 released
On Wed, Sep 24, 2014 at 03:43:10PM +0200, Tim Sander wrote: Hi I'm happy to announce that I've just released OSELAS.Toolchain-2013.12.2. This is a bugfix-only release. The relevant changes since 2013.12.1 are: - The toolchains can now be built with make 4.0 - Some toolchains did not optimize for the correct CPU. The code works but might be slower. This is fixed now. - All security relevant fixes mentioned in the glibc 2.19 changelog have been added for glibc 2.18 based toolchains. - All generated toolchain archives are now XZ comressed. While i have used this toolchain arm-v7a-linux-gnueabihf with an Xilinx Zynx compiling nearly the same Project with a different Kernelconfig /DTB for Altera SOC fails with this toolchain !?! The kernel boots but on mounting the rootfs it fails to execute any binary? Compiling the same project with OSELAS.Toolchain-2012.12.1/arm-cortexa9-linux- gnueabihf/gcc-4.7.3-glibc-2.16.0-binutils-2.22-kernel-3.6-sanitized does work however. I have also tried setting: PTXCONF_TARGET_EXTRA_CFLAGS=-mcpu=cortex-a9 -mfpu=neon PTXCONF_TARGET_EXTRA_CXXFLAGS=-mcpu=cortex-a9 -mfpu=neon But it still fails on executing any binary. Without knowing details about the two toolchains in question, this might be an ABI-problem. Does your kernel have OABI_COMPAT=y? Did you try to run a 2013.12.1 userspace with a 2012.12.1-compiled kernel and vice versa? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2013.12.2 released
Moin, Am 2014-05-07 10:07, schrieb Michael Olbrich: - All generated toolchain archives are now XZ comressed. Who generates this? Can I do this when building the toolchain? Up to now I do this manually. Greets Alex -- »With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie) *** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601 D1D5 8FBA 7744 CC87 10D0 *** -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2013.12.2 released
Hi, On Wed, May 07, 2014 at 10:41:33AM +0200, Alexander Dahl wrote: Am 2014-05-07 10:07, schrieb Michael Olbrich: - All generated toolchain archives are now XZ comressed. Who generates this? Can I do this when building the toolchain? Up to now I do this manually. this is done in the build_all_v2.mk script. For one toolchain I use e.g. $ ./build_one.sh arm-v7a-linux-gnueabihf This does some matching to find the correct config and calls build_all_v2.mk with the correct target to build on toolchain. The result is in inst/ and a tarball and Debian package (if dpkg is available) are generated in dist/. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2013.12.2 released
Hei hei, Am 2014-05-07 12:23, schrieb Michael Olbrich: On Wed, May 07, 2014 at 10:41:33AM +0200, Alexander Dahl wrote: Am 2014-05-07 10:07, schrieb Michael Olbrich: - All generated toolchain archives are now XZ comressed. Who generates this? Can I do this when building the toolchain? Up to now I do this manually. this is done in the build_all_v2.mk script. For one toolchain I use e.g. $ ./build_one.sh arm-v7a-linux-gnueabihf This does some matching to find the correct config and calls build_all_v2.mk with the correct target to build on toolchain. The result is in inst/ and a tarball and Debian package (if dpkg is available) are generated in dist/. I like the idea, however it does not work out of the box because of line 36 in build_all_v2.mk … ;-) But handy anyway, thanks for the hint. Greets Alex -- »With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie) *** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601 D1D5 8FBA 7744 CC87 10D0 *** -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2013.12.2 released
Hi, On Wed, May 07, 2014 at 01:16:10PM +0200, Alexander Dahl wrote: Am 2014-05-07 12:23, schrieb Michael Olbrich: On Wed, May 07, 2014 at 10:41:33AM +0200, Alexander Dahl wrote: Am 2014-05-07 10:07, schrieb Michael Olbrich: - All generated toolchain archives are now XZ comressed. Who generates this? Can I do this when building the toolchain? Up to now I do this manually. this is done in the build_all_v2.mk script. For one toolchain I use e.g. $ ./build_one.sh arm-v7a-linux-gnueabihf This does some matching to find the correct config and calls build_all_v2.mk with the correct target to build on toolchain. The result is in inst/ and a tarball and Debian package (if dpkg is available) are generated in dist/. I like the idea, however it does not work out of the box because of line 36 in build_all_v2.mk … ;-) But handy anyway, thanks for the hint. Well, I don't think I have any ptxdist based project without a 'p' link pointing to the correct ptxdist version... :-) Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2013.12.2 released
Am 2014-05-07 14:15, schrieb Michael Olbrich: Well, I don't think I have any ptxdist based project without a 'p' link pointing to the correct ptxdist version... :-) http://comments.gmane.org/gmane.comp.embedded.ptxdist.devel/8002 :) Regards, Bernhard -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2013.12.2 released
Hei hei, Am 2014-05-07 14:15, schrieb Michael Olbrich: On Wed, May 07, 2014 at 01:16:10PM +0200, Alexander Dahl wrote: I like the idea, however it does not work out of the box because of line 36 in build_all_v2.mk … ;-) But handy anyway, thanks for the hint. Well, I don't think I have any ptxdist based project without a 'p' link pointing to the correct ptxdist version... :-) Got it. The --force in the Makefile should not be necessary then. ;-) Thanks guys, this will simplify some things here for building and distributing new toolchains. :-) Greets Alex -- »With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie) *** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601 D1D5 8FBA 7744 CC87 10D0 *** -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2013.12.2 released
Hi, On Wed, May 07, 2014 at 03:01:50PM +0200, Alexander Dahl wrote: Am 2014-05-07 14:15, schrieb Michael Olbrich: On Wed, May 07, 2014 at 01:16:10PM +0200, Alexander Dahl wrote: I like the idea, however it does not work out of the box because of line 36 in build_all_v2.mk … ;-) But handy anyway, thanks for the hint. Well, I don't think I have any ptxdist based project without a 'p' link pointing to the correct ptxdist version... :-) Got it. The --force in the Makefile should not be necessary then. ;-) True. It's a relict from times when the script was less flexible. I should really remove it now... Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- ptxdist mailing list ptxdist@pengutronix.de
