linker finding object files

[n00b3]

Hello,

I am curious about just how exactly does the linker find the object files that it needs?

For example, if I have some code that includes the file iostream (#include <iostream>), c::b finds the object file iostream without me having to direct it to the file.  iostream resides in the following directory,
C:\Program Files\CodeBlocks\MinGW\include\c++\3.4.5

I assume this is the default directory for the linker to look for object files.  When I remove iostream from this directory my code will not compile.

In the settings > compiler and debugger all three search directories are empty and the Linker Libraries tab has no additional link libraries.  This is why I say, c::b is able to find the iostream object file just fine without my assistance.

However, when I include a my own headerfile myfunctions.h (#include <myfunctions.h>) now c::b needs me to tell it where myfunctions.o is.  Even if i place the myfunctions.o in the same directory as iostream, c::b cannot find the file.  I have to go into settings > compiler and debugger and add the myfunctions.o under the Linker Libraries tab.  If I leave the Linker Libraries empty, and fill in all three tab of search directory paths, c::b still cannot find the myfunctions.o.  But again, if I leave all the search directory paths empty and add myfunctions.o to the Linker Libraries all compiles well.

Alternatively, If I add myfunctions.h and myfunctions.cpp to the project everything compiles just fine, while leaving the Linker Libraries empty and leaving the search directory paths empty.

I am trying to understand why I have to manually (for each project that i include myfunctions.h) tell c::b where to find the myfunctions.o file while i do NOT have to tell c::b where to find the iostream file.

Please go easy on my ignorance.

Any and all help much appreciated.

Thanks,
DanK

[Deschamps]

I am trying to understand why I have to manually (for each project that i include myfunctions.h) tell c::b where to find the myfunctions.o file while i do NOT have to tell c::b where to find the iostream file

C::B acts as a mediator in this process, but it is gcc itself who knows where to find their own includes and libs, and the IDE doesn't decide anything in this business. For instance, try this from the command line:

Code

gcc -print-search-dirs

For all the other includes and libs, it's always needed that you specify where to find them, because the compiler can't decide for you the files you want to use in each case. You could have 20 different myfunctions.h headers spread in the whole hard disk.

Regards.

[n00b3]

Thanks for your response.

That makes sense...gcc knows where to find its own object files (iostream), and I understand the ambiguity that would result if I were not to specifically specify each of my own files.

Three follow-up questions:

1) I executed the command you mentioned above, and the path to the iostream object file was not listed, nor was the path to the iostream.h file.  There must be another variable for paths to "common" files or hard coded...?  Is this correct?

2)  When I place my header file in the same directory as iostream.h and make no changes to the compiler options, c::b finds my header, and doesn't seem to worry about any ambiguity (say if i had two headers with the same name in the same folder), but when I place my object file in the same directory as iostream object  file c::b does not find it.

3)  When I place my ojbect file in any of the paths listed by the search directory flag, gcc still does not find my object file. 

This all seems very odd behavior.  I would expect that the search directories listed by gcc would include the paths to iostream.h and the iostream object file, which it does not.  Also, I would expect that when I place my header files and object files in searchable directories they would either both be found or both not resolve due to ambiguity (and thus require specific user information).  However, it will find header files without my instructions, but not object files.

This raises the question...if you have to specify folder paths for anything 'user added', why even have a searchable directories variable as I would have to specify the file and folder path anyways?

If you tell me, "that is just the way c::b" was written, I can accept that.  But I guess I find it hard to believe this was designed this way.  I agree with your point about ambiguous names (i could have 20 different files on my disk with the same name), but then why am I not forced to specify the file and folder path of my header files, but I am for my object files?

Thanks,
DanK