My dear friends,
I'm trying to build C++ code for Linux running on am ARM Cortex A8 (TI AM335x). For a first try, I'm using the simplest program I can think of:
/* main.cpp */ int main() { return 0; }
Under Linux with the 'normal' GCC, that works fine, but under Windows 7 with the Linaro toolchain, it fails with the following message:
C:\firedect\dev\workspace\Test-Linux-ARM_1> "\Program Files (x86)\GNU Tools ARM Embedded\gcc-linaro-4.9-2016.02-i686-ming w32_arm-linux-gnueabi\bin\arm-linux-gnueabi-g++.exe" main.cpp c:/program files (x86)/gnu tools arm embedded/gcc-linaro-4.9-2016.02-i686-mingw32_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.4/../../../../arm-linux-gnueabi/bin/ld.exe:c:/program files (x86)/gnu tools arm embedded/gcc-linaro-4.9-2016.02-i686-mingw32_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.4/../../../../arm-linux-gnueabi/lib/libstdc++.so: file format not recognized; treating as linker script c:/program files (x86)/gnu tools arm embedded/gcc-linaro-4.9-2016.02-i686-mingw32_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.4/../../../../arm-linux-gnueabi/bin/ld.exe:c:/program files (x86)/gnu tools arm embedded/gcc-linaro-4.9-2016.02-i686-mingw32_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.4/../../../../arm-linux-gnueabi/lib/libstdc++.so:1: syntax error collect2.exe: error: ld returned 1 exit status
C:\firedect\dev\workspace\Test-Linux-ARM_1> "\Program Files (x86)\GNU Tools ARM Embedded\gcc-linaro-5.3-2016.02-i686-ming w32_arm-linux-gnueabihf\bin\arm-linux-gnueabihf-g++.exe" main.cpp c:/program files (x86)/gnu tools arm embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/bin/ld.exe:c:/program files (x86)/gnu tools arm embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so: file format not recognized; treating as linker script c:/program files (x86)/gnu tools arm embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/bin/ld.exe:c:/program files (x86)/gnu tools arm embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so:1: syntax error collect2.exe: error: ld returned 1 exit status
As you can see, I have tested two versions of the toolchain, which show the same behavior. Do you have any idea what's going wrong here? I'd appreciate any help you can provide!
On Wed, Apr 6, 2016 at 8:15 AM, Gunnar Arndt gunnar.arndt@vacos.de wrote:
embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so: file format not recognized; treating as linker script c:/program files (x86)/gnu tools arm embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/bin/ld.exe:c:/program files (x86)/gnu tools arm embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so:1: syntax error collect2.exe: error: ld returned 1 exit status
I get a slightly different error when I try this. I get the file format not recognized error, but then it quits instead of trying to read it as a linker script.
The file in question is a symlink. If you use a cygwin tar binary to extract the tar.xz file on the windows machine, then cygwin by default creates cygwin style symlinks, which can only be understood by cygwin programs. The toolchain we released is not a cygwin binary, so it can't follow these symlinks, and you get the error. I see two ways to solve this problem.
1) In cygwin, you can do "export CYGWIN=winsymlinks" before extracting the tar.xz file. You will then get a windows short-cut instead of a cygwin style symlink, and the toolchain will work. https://cygwin.com/faq.html#faq.api.symlinks The faq mentions different ls output, but I didn't see that. I do see a difference in file explorer. The cygwin so symlink appears as type "SO File", where as the windows short-cut appears as type "Shortcut".
2) Use a non-cygwin program to extract the package. I don't know if there is a non-cygwin tar available, but you could extract on a linux machine, use zip to create a zip/pkzip archive, and then use a windows unzip/pkzip program to extract it. I didn't try this, but this should in theory work.
Jim
Hi Jim,
thank you for the competent suggestion. I had used 7-Zip to extract the archive, which has nothing to do with Cygwin. However, I remember that there were indeed some hints about files being overwritten by identical ones - those probably were the links in question. I'm going to give your suggestion a try and report back.
Gunnar Arndt
Am 07.04.2016 um 03:20 schrieb Jim Wilson:
On Wed, Apr 6, 2016 at 8:15 AM, Gunnar Arndt gunnar.arndt@vacos.de wrote:
embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so: file format not recognized; treating as linker script c:/program files (x86)/gnu tools arm embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/bin/ld.exe:c:/program files (x86)/gnu tools arm embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so:1: syntax error collect2.exe: error: ld returned 1 exit status
I get a slightly different error when I try this. I get the file format not recognized error, but then it quits instead of trying to read it as a linker script.
The file in question is a symlink. If you use a cygwin tar binary to extract the tar.xz file on the windows machine, then cygwin by default creates cygwin style symlinks, which can only be understood by cygwin programs. The toolchain we released is not a cygwin binary, so it can't follow these symlinks, and you get the error. I see two ways to solve this problem.
- In cygwin, you can do "export CYGWIN=winsymlinks" before extracting
the tar.xz file. You will then get a windows short-cut instead of a cygwin style symlink, and the toolchain will work. https://cygwin.com/faq.html#faq.api.symlinks The faq mentions different ls output, but I didn't see that. I do see a difference in file explorer. The cygwin so symlink appears as type "SO File", where as the windows short-cut appears as type "Shortcut".
- Use a non-cygwin program to extract the package. I don't know if
there is a non-cygwin tar available, but you could extract on a linux machine, use zip to create a zip/pkzip archive, and then use a windows unzip/pkzip program to extract it. I didn't try this, but this should in theory work.
Jim
Jim,
I've unzipped the Linaro gcc archive with WinRAR, and - what probably makes the difference - chosen NOT to overwrite duplicate files during unzipping. It works now for simple test programs, but I fear that there will be problems some time soon because of content not properly extracted.
Gunnar Arndt
Am 07.04.2016 um 03:20 schrieb Jim Wilson:
On Wed, Apr 6, 2016 at 8:15 AM, Gunnar Arndt gunnar.arndt@vacos.de wrote:
embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so: file format not recognized; treating as linker script c:/program files (x86)/gnu tools arm embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/bin/ld.exe:c:/program files (x86)/gnu tools arm embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so:1: syntax error collect2.exe: error: ld returned 1 exit status
I get a slightly different error when I try this. I get the file format not recognized error, but then it quits instead of trying to read it as a linker script.
The file in question is a symlink. If you use a cygwin tar binary to extract the tar.xz file on the windows machine, then cygwin by default creates cygwin style symlinks, which can only be understood by cygwin programs. The toolchain we released is not a cygwin binary, so it can't follow these symlinks, and you get the error. I see two ways to solve this problem.
- In cygwin, you can do "export CYGWIN=winsymlinks" before extracting
the tar.xz file. You will then get a windows short-cut instead of a cygwin style symlink, and the toolchain will work. https://cygwin.com/faq.html#faq.api.symlinks The faq mentions different ls output, but I didn't see that. I do see a difference in file explorer. The cygwin so symlink appears as type "SO File", where as the windows short-cut appears as type "Shortcut".
- Use a non-cygwin program to extract the package. I don't know if
there is a non-cygwin tar available, but you could extract on a linux machine, use zip to create a zip/pkzip archive, and then use a windows unzip/pkzip program to extract it. I didn't try this, but this should in theory work.
Jim
On Thu, Apr 7, 2016 at 2:43 AM, Gunnar Arndt gunnar.arndt@vacos.de wrote:
I've unzipped the Linaro gcc archive with WinRAR, and - what probably makes the difference - chosen NOT to overwrite duplicate files during unzipping. It works now for simple test programs, but I fear that there will be problems some time soon because of content not properly extracted.
Perhaps the issue is that the windows programs are confused by the linux file names in the tar file. Some of the file names have more than one dot for instance. I will have to try one of the programs you mentioned later today. If this is the case, then you might need to use a linux tar to properly extract it, which means for instance the cygwin tar, with winsymlinks set.
Jim
On Thu, Apr 7, 2016 at 2:43 AM, Gunnar Arndt gunnar.arndt@vacos.de wrote:
I've unzipped the Linaro gcc archive with WinRAR, and - what probably makes the difference - chosen NOT to overwrite duplicate files during unzipping. It works now for simple test programs, but I fear that there will be problems some time soon because of content not properly extracted.
I tried 7-zip. In the extract window, there is a list of errors, which reports that every symlink create failed. It creates 0 size files instead, which obviously won't work, and will give the error you saw. I tried WinRAR. It also gave an error for every symlimk, but produced a more useful error message that says I have to use administrator mode. It copies the symlink target into the symlink instead, so I get a 8.9MB libstdc++.so file instead of the symlink I was expecting. This does work, but will waste some disk space. Both of these problems are fixed by running 7-zip or WinRAR as the administrator. I get correct symlinks in both cases.
The other problem with the duplicate files is due to a linux kernel package called netfilter. Linux has case insensitive filesystems, and netfilter has some file names that differ only in case, e.g. /usr/include/linux/netfilter_ipv6/ip6t_hl.h and ip6t_HL.h. This is unfriendly to windows which is case preserving, but not case insensitive. It looks like even cygwin is getting this wrong. There isn't much that can be done about this. But this is only an issue if you want to use the netfilter package, which is not common in application programs. If you do need to use netfilter, then you may need to use a linux hosted cross compiler instead of a windows hosted cross compiler.
Jim
Actually NTFS can be made to be case sensitive.
-----Original Message----- From: linaro-toolchain [mailto:linaro-toolchain-bounces@lists.linaro.org] On Behalf Of Jim Wilson Sent: Thursday, April 7, 2016 5:26 PM To: Gunnar Arndt gunnar.arndt@vacos.de Cc: Linaro Toolchain Mailman List linaro-toolchain@lists.linaro.org Subject: Re: Linaro toolchain: libstdc++.so: file format not recognized; treating as linker script
On Thu, Apr 7, 2016 at 2:43 AM, Gunnar Arndt gunnar.arndt@vacos.de wrote:
I've unzipped the Linaro gcc archive with WinRAR, and - what probably makes the difference - chosen NOT to overwrite duplicate files during unzipping. It works now for simple test programs, but I fear that there will be problems some time soon because of content not properly extracted.
I tried 7-zip. In the extract window, there is a list of errors, which reports that every symlink create failed. It creates 0 size files instead, which obviously won't work, and will give the error you saw. I tried WinRAR. It also gave an error for every symlimk, but produced a more useful error message that says I have to use administrator mode. It copies the symlink target into the symlink instead, so I get a 8.9MB libstdc++.so file instead of the symlink I was expecting. This does work, but will waste some disk space. Both of these problems are fixed by running 7-zip or WinRAR as the administrator. I get correct symlinks in both cases.
The other problem with the duplicate files is due to a linux kernel package called netfilter. Linux has case insensitive filesystems, and netfilter has some file names that differ only in case, e.g. /usr/include/linux/netfilter_ipv6/ip6t_hl.h and ip6t_HL.h. This is unfriendly to windows which is case preserving, but not case insensitive. It looks like even cygwin is getting this wrong. There isn't much that can be done about this. But this is only an issue if you want to use the netfilter package, which is not common in application programs. If you do need to use netfilter, then you may need to use a linux hosted cross compiler instead of a windows hosted cross compiler.
Jim _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
On Thu, Apr 7, 2016 at 7:46 PM, Pinski, Andrew Andrew.Pinski@caviumnetworks.com wrote:
Actually NTFS can be made to be case sensitive.
Good point. I'd forgotten about that. See https://cygwin.com/cygwin-ug-net/using-specialnames.html about 1/3 of the way down it talks about turning off case insensitive filenames with a registry change. I don't know what this will do to windows programs that might not be expecting case sensitive filenames..
Jim
Jim and Andrew,
thank you for the details. I agree with Jim that it is probably dangerous to dig into Windows too deeply, so I'll accept the mentioned waste of disk space caused by target files copied to symlinks, as there is usually by far enough of it these days.
Regards, Gunnar Arndt
linaro-toolchain@lists.linaro.org
-
Gunnar Arndt -
Jim Wilson -
Pinski, Andrew