Linaro toolchain: libstdc++.so: file format not recognized; treating as linker script

[Gunnar Arndt]

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!

[Jim Wilson]

Post by Gunnar Arndt
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
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

[Gunnar Arndt]

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

Post by Jim Wilson

Post by Gunnar Arndt
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
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

[Gunnar Arndt]

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

Post by Jim Wilson

Post by Gunnar Arndt
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
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

[Jim Wilson]

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

[Jim Wilson]

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

[Pinski, Andrew]

Actually NTFS can be made to be case sensitive.

-----Original Message-----
From: linaro-toolchain [mailto:linaro-toolchain-***@lists.linaro.org] On Behalf Of Jim Wilson
Sent: Thursday, April 7, 2016 5:26 PM
To: Gunnar Arndt <***@vacos.de>
Cc: Linaro Toolchain Mailman List <linaro-***@lists.linaro.org>
Subject: Re: Linaro toolchain: libstdc++.so: file format not recognized; treating as linker script

Post by Gunnar Arndt
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-***@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Jim Wilson]

On Thu, Apr 7, 2016 at 7:46 PM, Pinski, Andrew

Post by Pinski, Andrew
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

[Gunnar Arndt]

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