Author Topic: Linking Problem now...  (Read 10156 times)

russose

  • Guest
Linking Problem now...
« on: December 27, 2005, 01:33:00 pm »
Hallo,

First Thanks for this very good program. I discovered it a few weeks ago and I am very happy with it.
But I have some problems...

1) I am working on a workspace with 30 projects (imporrted from VC6 projects). One of this project is the main executable and the other projects are internal libraries. Everythink is compiling fine but during linking, if I specify the libraries to use in the 'build option' of the main project, Code::Blocks doesn't manage to link (lot of unresolved external function blbla). But if I specify these libraries in 'setting->compiler->linker', it works fine... each time I will update code::block, I will have to do it :=( ??

2) I am using python.lib and I had problems to link it. With the RC2, it was not working... I had thousands of 'undefined reference to blabla' but not in red... I only managed to make it link if I ONLY specified "python23" in 'setting->compiler->linker' and specified the right directory in 'setting->compiler->directory->linker'... it was the only way to make it link (I tried almost everythink else possible :=) )

3) But when my application was running, I wanted to use the debugger but it was not working with breakpoints . So I downloaded gdb 6.3 and a the last version CodeBlocksSVN20051224.7z. The good surprise is that the debugger is working very good!! But now, if I build my application again, I have no way to link python :=( "python23" is not found... I have to pick it from the codeblock explorer but then, I have these 100000 unresolved imp_blabla.

Has someone an idea about what I am doing wrong? Is there a way to easily link my library specifying locally in the project option everything (to share it also).

Thanks for your help,
Salvatore

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Linking Problem now...
« Reply #1 on: December 27, 2005, 01:56:10 pm »
1) This is most likely because you were using #pragma lib or whatever it is called.
It is not your fault, blame Microsoft. People who use MS products often have that kind of problem because they do things which they have learned as "correct and normal" when in fact it is not correct and normal at all, but MS teaches you so.
If you need to link to a library, you certainly have to tell the linker to do that (usually via the commandline, but MS also has this pragma stuff).
You will not have to do it again every time you update Code::Blocks, as this gets saved with your project (you will have to do it if you re-import, though).

2) You should use .a libraries instead of .lib (use the tool reimp which comes with MinGW to convert the lib if you don't have a .a library). The correct way to add libraries is by either providing the name (without prefix or extension), so the IDE will complete the filename, or (not recommended) by providing a full path/filename. Alternatively, you can add -lyourLibraryName to the command line options, but again this is not recommended (it is complicated and not necessary, the IDE can do the dirty work for you).

3) Yes, the debugger has lately been greatly improved, you should always use a recent build for debugging.
Please note that RC2 and the build from HEAD use different methods to store the configuration. So you will have to set up the system lib directories again when migrating to HEAD (this may be why the lib is not found).

EDIT:
1) and 2)  Of course you can just use the MSVC toolkit with Code::Blocks, too. In that case, the #pragma works again.
« Last Edit: December 27, 2005, 01:57:47 pm by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

russose

  • Guest
Re: Linking Problem now...
« Reply #2 on: December 27, 2005, 02:55:59 pm »
Hallo Thomas,

Thanks for your quick (!) answer.

1) The project are not using pragma (because it should compile on every platform... mac, linux, windows. So the problem should not be here.
Do I really understood good: information stored in "setting->compiler" are saved with the projects? I didn't experience that. When I opened my project on an other computer, I had to write all information again... but maybe I made something wrong??

2) I will try again what you advise... I will only write the nane of libraries in "build opetion-> linker" and give the directoriy separatly in "directory->linker"...

3) ah ok, I will built everything again...

Thanks again for your help and I hope I will make it work.
Salvatore

russose

  • Guest
Re: Linking Problem now...
« Reply #3 on: December 27, 2005, 10:08:54 pm »
After some checks, it seems that the problem was caused by differencies between the list of linked library in "build option->linker" and "setting->compiler->linker"
If there are differencies, then I receive strange ling error, "unresolved external function..." but everything works fine if the list of library is the same... strange behaviour.

I also noticed that a problem could come from "space in directory name" such "Programm Files" (we have to write "Program~1".

Now everything is working really good!! Thanks for this amazing programm!

Salvatore

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Linking Problem now...
« Reply #4 on: December 27, 2005, 10:19:11 pm »
Do I really understood good: information stored in "setting->compiler" are saved with the projects?
No, the compiler settings are stored in the config (registry for RC2, XML file for HEAD). The build options which you can access by right-clicking the project are stored in the project file. This is the correct place to put the link libraries, too, since they depend on the project, and do not apply to every program which you possibly write.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

russose

  • Guest
Re: Linking Problem now...
« Reply #5 on: December 29, 2005, 10:30:14 am »
Hallo Thomas,

I understand but if I don't write my link libraries in BOTH places, the linker complains. If the seetings are in a XML file, I will restore it after an update to avoid writting all links again.

Thanks for your help,
Salvatore

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Linking Problem now...
« Reply #6 on: December 29, 2005, 05:01:32 pm »
If you add your link libraries to the project alone, this should be enough.

If that causes a problem, then you are not doing it correctly. Seriously, it must work that way, everybody is doing it, it is the correct way to do it.

Everything that is global for every project goes into compiler settings (that might for example be your system include path), but everything that may vary among different projects (like link libraries) really should go into the project file.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Linking Problem now...
« Reply #7 on: December 29, 2005, 06:18:10 pm »
Maybe he's adding the libraries in the wrong order and those libraries depend some on another. Having them twice is what could be solving the problem, but just by adding them in the right order in the project options should be enough.

As a real life example, in the old days when I used Allegro, if you wanted to load a PNG you'd need to link against 4 libraries: allegro, zlib, png and loadpng. If you added them in the wrong order you'd get lots of unresolved symbols, because some of those rely on some other. There, png relies on zlib and loadpng relies on both allegro and png. That said, the right order would be: loadpng png zlib allegro (since zlib and allegro don't rely one on each other you could also swap them).

If that's your case, consider the order and try again :)

russose

  • Guest
Re: Linking Problem now...
« Reply #8 on: December 29, 2005, 06:35:03 pm »
Hallo,

I totally agree with you :=) I agree that the project option is the ONLY good place. But in practice, it was not working... and after some days of fight I solved the problem with the global option.

The order of the libraries could be a solution. I already thought about this and tried a little to change the order but given I have 20-30 libraries, if there is one combinaison, it will be a good game to find it :=) I have more chances to win a loto :=)

Seriously, I will try again, maybe 3 or 4 libraries are used by everyone.... their order can be important... I will try again :=)

Thanks for your help,
Salvatore

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Linking Problem now...
« Reply #9 on: December 29, 2005, 08:02:25 pm »
From personal experience, the libraries at the top depend on the libraries at the bottom.

russose

  • Guest
Re: Linking Problem now...
« Reply #10 on: January 02, 2006, 09:49:32 am »
Hallo,

Back home, I tried what you adviced and it worked :=) The problem was coming from the order of linked libraries. So I only write the library in the project option with to "most used libraries" down (global libraries...). After some tuning, it worked.

Thanks again,
Salvatore