Compiling Issues With Code::blocks On Windows

[ManDudeGuy]

I've spent hours on trying to get this to work...
And yes I've searched both Google and these forums.

The Problem:
While using Code::Blocks to compile for the Caanoo.
I'm attempting to compile a simple Hello World application, and I have received this error...
D:\PATH_TO_SDK\tools\cross-eabi\arm-gph-linux-gnueabi\sys-root\lib/libstdc++.so: file not recognized: File format not recognized

My Situation:
I've setup the configuration for a "Caanoo GCC Toolchain" in Code::Blocks global compiler settings
Compiler paths:
D:\PATH_TO_SDK\DGE\include
D:\PATH_TO_SDK\include
D:\PATH_TO_SDK\tools\cross-eabi\arm-gph-linux-gnueabi\sys-root\usr\include
D:\PATH_TO_SDK\tools\cross-eabi\arm-gph-linux-gnueabi\include\c++\4.2.4\arm-gph-linux-gnueabi
D:\PATH_TO_SDK\tools\cross-eabi\arm-gph-linux-gnueabi\include\c++\4.2.4

Linker paths:
D:\PATH_TO_SDK\DGE\lib\target
D:\PATH_TO_SDK\lib\target
D:\PATH_TO_SDK\tools\cross-eabi\arm-gph-linux-gnueabi\sys-root\usr\lib
D:\PATH_TO_SDK\tools\cross-eabi\arm-gph-linux-gnueabi\sys-root
D:\PATH_TO_SDK\tools\cross-eabi\arm-gph-linux-gnueabi\sys-root\lib

ToolChain Additional Paths:
D:\PATH_TO_SDK\tools\cross-eabi\arm-gph-linux-gnueabi\bin
D:\PATH_TO_SDK\tools\cross-eabi\libexec\gcc\arm-gph-linux-gnueabi\4.2.4
D:\PATH_TO_SDK\tools\cross-eabi\arm-gph-linux-gnueabi\sys-root\usr\lib
D:\PATH_TO_SDK\tools\cross-eabi\arm-gph-linux-gnueabi\sys-root\lib

ToolChain Main Path:
D:\PATH_TO_SDK\tools\cross-eabi

I've used the Code::Blocks installer which filename does not mention "MinGW", I had the intention of using another toolchain for compiling on Windows.

I've also had to copy crt1.o into my project folder in order to get where I am now.

Let me know if you require more information and thanks for any assistance you can render.

I'm very apprehensive about posting, this is my first. Please... be kind with any criticism of my posting etiquette.

Sincerely,
-MDG

 

[Farox]

My Situation:
I've setup the configuration for a "Caanoo GCC Toolchain" in Code::Blocks global compiler settings
Compiler paths:
D:\PATH_TO_SDK\DGE\include
D:\PATH_TO_SDK\include
D:\PATH_TO_SDK\tools\cross-eabi\arm-gph-linux-gnueabi\sys-root\usr\include
D:\PATH_TO_SDK\tools\cross-eabi\arm-gph-linux-gnueabi\include\c++\4.2.4\arm-gph-linux-gnueabi
D:\PATH_TO_SDK\tools\cross-eabi\arm-gph-linux-gnueabi\include\c++\4.2.4

try to add a this line here D:\PATH_TO_SDK\tools\cross-eabi\lib\gcc\arm-gph-linux-gnueabi\4.2.4\include

The rest is the same on my setup.
Happy compiling

 

[ManDudeGuy]

Thanks for the reply Farox.

try to add a this line here D:\PATH_TO_SDK\tools\cross-eabi\lib\gcc\arm-gph-linux-gnueabi\4.2.4\include

Well I added that extra include folder you mentioned, and I'm still getting the same error.
The good ol'
"D:\PATH_TO_SDK\tools\cross-eabi\arm-gph-linux-gnueabi\sys-root\lib/libstdc++.so: file not recognized: File format not recognized"

 

[Farox]

I'm not an expert ..i have only followed this guide ...http://edorul.free.fr/dokuwiki/doku.php?id=prog:caanoosdk_install_eng and works.
Maybe its the non MinGW version of compiler...that didn't work.

 

[ManDudeGuy]

I think I figured it out... The compiler/linker or whatever doesn't like these "symbolic links".

I've investigated the file in question, to my surprise this library was only 50 bytes. So I opened it wondering what this file was. It seems to be a symbolic link of some kind given the information inside the file: "!<symlink>". I've changed the file names around to have the actual library have that name. It seemed to have worked, but I'm still skeptical of this little "hack", and that it may end up back firing on me in the future.

Let me know what you think of this. Personally I believe what I'm doing may lead to problems in the future, and I'm not sure what to do at this point.

Thanks,
-MDG

 

[hmn]

I think I figured it out... The compiler/linker or whatever doesn't like these "symbolic links".

These files are Cygwin's way of emulating symlinks on Windows. Applications built against Cygwin (such as the toolchain AFAIK) should be able to open these
transparently... are the Cygwin DLLs on your %PATH% ?

I've investigated the file in question, to my surprise this library was only 50 bytes. So I opened it wondering what this file was. It seems to be a symbolic link of some kind given the information inside the file: "!<symlink>". I've changed the file names around to have the actual library have that name. It seemed to have worked, but I'm still skeptical of this little "hack", and that it may end up back firing on me in the future.

Let me know what you think of this. Personally I believe what I'm doing may lead to problems in the future, and I'm not sure what to do at this point.

Replacing these "symlinks" with actual copies of the files they link to should not be a problem, but it should not be nescessary either...


PS: It is always helpful to configure CodeBlocks to print the actual command lines issued in the compilation log...

 

[Farox]

I think that Cygwin will do the symlinks for all the libs.
I have had a similar problem with a very old toolchain for Pandora, resolved making a multiple copy of the lib...let me explain:

You have in the folder a lib named libstdc++.so.6.0.9 (about 690KB) but the linker want to use name libstdc++.so.6 or libstdc++.so
So to correct this you could make a copy of libstdc++.so.6.0.9 and rename 2 time with libstdc++.so.6 and libstdc++.so
Now you have 3 copy (all with the same size...690KB) of this lib.

Please pay attention that you have to repeat this operation for all the libs inside the toolchain.
I think its better to install the toolchain suggested on my precedent link if you can.

Hope that will be usefull for you and sorry for the not very clear english...

 

[ManDudeGuy]

These files are Cygwin's way of emulating symlinks on Windows. Applications built against Cygwin (such as the toolchain AFAIK) should be able to open these
transparently... are the Cygwin DLLs on your %PATH% ?

Yup, Cygwin DLLs are present and the directory is in the %PATH%

You have in the folder a lib named libstdc++.so.6.0.9 (about 690KB) but the linker want to use name libstdc++.so.6 or libstdc++.so
So to correct this you could make a copy of libstdc++.so.6.0.9 and rename 2 time with libstdc++.so.6 and libstdc++.so
Now you have 3 copy (all with the same size...690KB) of this lib.

This would be a very tedious task due to there being so many of these shared objects and symbolic links.

I may try doing it on Linux. There's quite a few things I need to setup before attempting it, but I'll let you guys know what happens.

If everyone doesn't mind I'm going to drop the issue for Christmas and try at it again on the 26th.

Btw Farox, I didn't notice anything off with your English.

Many Thanks,
-MDG

 

[Farox]

Wait...if you have also installed Cygwin don't need to do all the copy/renaming libs ...it should work as is.
Maybe just uninstall all the Toolchain and reinstall it....or maybe depend on Windows version.

 

[ManDudeGuy]

Maybe just uninstall all the Toolchain and reinstall it....or maybe depend on Windows version.

Tried reinstalling the toolchain and it made no difference.
I'm using Windows 7 x64.

I still can't figure this out...

Thanks for helping me through this.

-MDG

 

[hmn]

Have you turned on full command line logging?

If so, what does it print before the error message?

 

[ManDudeGuy]

Here's what comes out, with full command line enabled

idc about anyone knowing my actually directory structure anymore.

arm-gph-linux-gnueabi-g++.exe -LD:\Development\C++\bin\caanoo\sdk\DGE\lib\target -LD:\Development\C++\bin\caanoo\sdk\lib\target -LD:\Development\C++\bin\caanoo\sdk\tools\cross-eabi\arm-gph-linux-gnueabi\sys-root\usr\lib -LD:\Development\C++\bin\caanoo\sdk\tools\cross-eabi\arm-gph-linux-gnueabi\sys-root -LD:\Development\C++\bin\caanoo\sdk\tools\cross-eabi\arm-gph-linux-gnueabi\sys-root\lib -o bin\Debug\HelloWorld.exe "obj\Debug for Caanoo\src\HelloWorld.o"
cygwin warning:
MS-DOS style path detected: obj\Debug for Caanoo\src\HelloWorld.o
Preferred POSIX equivalent is: obj/Debug for Caanoo/src/HelloWorld.o
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
D:\Development\C++\bin\caanoo\sdk\tools\cross-eabi\arm-gph-linux-gnueabi\sys-root\usr\lib/libm.so: file not recognized: File format not recognized
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings

I'm hoping it will be immediately apparent what I did wrong. As for the output binary I cannot remove the ".exe" extension, CodeBlocks adds it back as soon as I remove it.

-MDG

 

[Farox]

I can't help you on this problem, but i can on the extension problem.
When you have your project open go to the menu .... Project-->Properties now select the Tab Build Targets and untick the 2 options

• Auto-generate filename prefix
• Auto-generate filename extension

and now you can change and choise the name you want for you prog.

 

[hmn]

The command line seems to offer no clues...

I still think something must be wrong with your cygwin installaton. It might have to do something with the file systems, since Cygwin now seems to support "native" symlinks as well (available since Vista on NTFS).
Which file system is used for drive D? Is Cygwin installed on the same drive?

You could try to navigate to the folder containing libm.so in a cygwin shell, then issue the command "file libm.so" to see if it is recognized
by Cygwin as a symbolic link.

 

[ManDudeGuy]

hmn,

Which file system is used for drive D?

D is a "documents" drive formatted as NTFS, this drive also contains everything programming related (among other things).
Maybe I didn't understand the question...

Cygwin is not installed on the same drive.
(Well different partition, same volume though I don't think that would make a difference software wise.)

Cygwin seems to see the symbolic link libm.so as data?

me@mymachine /cygdrive/d/Development/C++/bin/caanoo/sdk/tools/cross-eabi/arm-gph-linux-gnueabi/sys-root/usr/lib
$ file libm.so
libm.so: data

Just trying to make sure everything is clear.

Thanks,
-MDG

 

[hmn]

To see if the drives/file systems make a difference, you could try copying that libm.so file over to the drive where Cygwin is installed and repeat the procedure. It should then print something like "libm.so: Broken symbolik link...".

If it does, then you could just re-install the SDK on the same drive as Cygwin (or maybe the other way around).

If it still says "data", then you could investigate the symlinks installed by Cygwin itself. For example, it should have installed "awk" as a symlink to "gawk.exe" in the "C:\Cygwin\bin" folder (or whereever you installed it). In the Cygwin shell, enter "awk --version" and see if that produces the version info or an error message.

If you get the error message, then it would look like the whole Cygwin installation is broken. If it works, then you should investigate how the link (C:\Cygwin\bin\awk) looks like and how it is different from the libm.so link...

 

[ManDudeGuy]

I apologize for the lateness of this response.
Well... Tried it, with no difference...

I copied the sdk to the Cygwin home folder and the problem persists.
It doesn't seem to have a problem with "awk --version" (It prints out info on GNU Awk).

Did I make a wrong turn somewhere?

Thanks,
-MDG

 

[hmn]

Hmmm, I'm out of ideas... maybe you could start over, or ask some Cygwin specialists for help...

 

[sdm]

As Farox assumed in post #4:

Maybe its the non MinGW version of compiler...that didn't work.

It is also written in Quck Installation Guide:

Note: Codeblocks including MinGW should be installed for the native compiler.

Did you try it?