Linker problem after importing DevCpp project

[ijese]

Hi. I'm new with CB and it looks great, but I have a problem rebuilding the imported DevCpp project 

I'm using CB1rc2 with MinGW 3.4.2 from DevCpp. "libFOX.a" is compiled and linked with the same gcc. What's wrong?

Project   : TEST MockupScreens
Compiler  : GNU GCC Compiler (called directly)
Directory : C:\igor\projekti\radni\mockupscreens\tests\
--------------------------------------------------------------------------------
Switching to target: default
mingw32-g++.exe   -L..\libs  -LC:\Dev-Cpp\lib -o C:\IGOR\projekti\radni\mockupscreens\tests\Storyboardz.exe obj\src\Checkbox.o obj\src\Dropdown.o obj\src\FloatText.o obj\src\Form.o obj\src\Frame.o obj\src\LabeledDropdown.o obj\src\LabeledField.o obj\src\Project.o obj\src\SImage.o obj\src\SLabeledList.o obj\src\SLine.o obj\src\SMark.o obj\src\SMultilineText.o obj\src\SRadio.o obj\src\STList.o obj\src\STable.o obj\src\STabs.o obj\src\STextLink.o obj\src\STitle.o obj\src\STree.o obj\src\Scenario.o obj\src\Screen.o obj\src\Storyboardz.o obj\src\Subject.o obj\src\ViewProjectScenarios.o obj\src\ViewScenarioScreens.o obj\src\ViewScreenElements.o obj\src\ViewScreenForm.o obj\src\Widget.o obj\src\WinAbout.o obj\src\WinOptions.o obj\src\WinProjectMain.o obj\src\WinScreenEditor.o obj\src\WinSlideShow.o obj\src\WinSplash.o obj\src\WinTableEditor.o obj\src\button.o obj\src\storyboardz_utils.o obj\src\textfield.o obj\src\textlabel.o obj\tests\ButtonTest.o obj\tests\FormTest.o obj\tests\GuiTestRefresh.o obj\tests\GuiTestWidgetEdit.o obj\tests\GuiTestWidgetFields.o obj\tests\GuiTestWidgetTabs.o obj\tests\GuiTestWidgetTransform.o obj\tests\ProjectTest.o obj\tests\STableTest.o obj\tests\ScenarioTest.o obj\tests\ScreenTest.o obj\tests\TestDefinirajEkran.o obj\tests\WidgetTest.o obj\tests\WinTestResults.o obj\tests\main.o     -mwindows -e _mainCRTStartup -lFOX -lcpptest -ljpeg -lcomctl32 -lwsock32 -lwinspool -lmpr -lpng -lm -lz
..\libs/libFOX.a: file not recognized: File format not recognized
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 1 seconds)
0 errors, 0 warnings

[mandrav]

What's wrong?

..\libs/libFOX.a: file not recognized: File format not recognized

It tells you exactly what's wrong...

[rcoll]

What's wrong?

..\libs/libFOX.a: file not recognized: File format not recognized

It tells you exactly what's wrong...

I don't get this.  If "libFOX.a" is compiled and linked with the same gcc, why is
the file format not recognized later by gcc?  There might be a problem with switch
args, or backslash styles ("/" vs "\") but I would expect a different message from
gcc than "invalid file format".

-- Ron --

[ijese]

What's wrong?

..\libs/libFOX.a: file not recognized: File format not recognized

It tells you exactly what's wrong...

If you can see what's wrong please explain. And thank you for your time...

[mandrav]

If I have to

a) believe what ijese thinks libfox.a is, or
b) believe what gcc thinks libfox.a is

then, sorry, I have to go with (b). I trust gcc more

Have you tried to see the contents of libfox.a? Its size? Have you investigated the file?

[ijese]

libFOX.a is a same fox-toolkit library file which I use for several projects.

15mins ago I have built a Fox "hello-world" with CB using the same file (I copied it from the project which doesn't link). I even tried the variations with nested directories and such and it still worked fine.

Right now I'm trying to create the CB project from scratch (without dev-cpp import). It might work and if not I still might get some clue.

[thomas]

It tells you exactly what's wrong...

If you can see what's wrong please explain.

Just read. The file that the linker tries to open is  not good.

libFOX.a is a same fox-toolkit library file which I use for several projects.

No, you think it is, but it is obviously not- the linker would not complain if it were. Check your linker paths and remove everything you don't need.

15mins ago I have built a Fox "hello-world" with CB using the same file (I copied it from the project which doesn't link). I even tried the variations with nested directories and such and it still worked fine.

That's just the cause that often creates such a mess. Never copy around headers or libraries unless there is a good reason to do so, and never work with several versions of the same file at the same time.
One should ideally keep exactly one version of everything in one place. Then there is no question about whether the right file is used.

[ijese]

No, you think it is, but it is obviously not- the linker would not complain if it were. Check your linker paths and remove everything you don't need.

The from-scratch approach didn't work either, so I'm doing this clean-up right now. Of course it probably is my fault but I (maybe wrongly) expected that something that worked in dev-cpp would work after import in CB without much trouble.

Currently I'm getting different errors: a lot of unresolved _imp_* which do exists in library (i checked with nm) but without "_imp_" mangled in. I want to link everything statically in one executable file but it seems ld expects libraries which will be used dinamicaly or something like that, I'm not exactly an c++ expert so I'm barely swimming.

That's just the cause that often creates such a mess. Never copy around headers or libraries unless there is a good reason to do so, and never work with several versions of the same file at the same time. One should ideally keep exactly one version of everything in one place. Then there is no question about whether the right file is used.

The problem arises when I want to fix a bug in a project from 3 years ago. In my experience the safest thing is to store everything including libs in cvs.