Page 1 of 1
gcc does not recognise local headerfiles any more
Posted: Tue Oct 11, 2011 7:24 pm
by JosDuchIt
All of a sudden gcc does not find the includes in the same drawer (#include thisheader.h) as the source file.
Is there some file i did lose describing gcc's searchpath?
Answer: no
The problem happened when i made an assign for a long path
assign snips: datas:dev/workingsnippets/
gcc datas:dev/workingsnippets/Myfile.c -o ram:Myfile worked ok
gcc snips:Myfile.c -o ram:Myfile did not recognise the includes
Re: gcc does not recognise local headerfiles any more
Posted: Tue Oct 11, 2011 11:12 pm
by zerohero
gcc snips:Myfile.c -o ram:Myfile did not recognise the includes
It only searches the current dir, which is not what you want. Either compile from the dir or use "-I/snips/" (maybe -Isnips: works too) on the command line.
Re: gcc does not recognise local headerfiles any more
Posted: Fri Oct 14, 2011 9:57 am
by JosDuchIt
Hi zerohero
I made the following testst (of course if you compile from the sources directory no problem, but then you have to reset with "cd" each time if you want to compile a file in another directory, and you can't use the shell's history as easily.
A while ago i discovered local includes (next to the file you want to compile) were recognised as well if you used a path of the file to compile as in this example. ( guis: is an assign, no volume)
8.Amiga OS 4:S> gcc guis:Dev/G4C_2011a/GuiGetIFceWorks.c -lauto -o guis:g4t11b
works OK
What i discoverd now was that this does not work if that path is just an assign
8.Amiga OS 4:S> assign 2011a: guis:Dev/G4C_2011a/
8.Amiga OS 4:S> gcc 2011a:GuiGetIFceWorks.c -lauto -o guis:g4t11b
does not recognise local includes in 2011a:
I think that must be easy to fix.
So this might be taken up (or not) by the SDK developers.
====
I tested your suggestions:
8.Amiga OS 4:S> gcc GuiGetIFceWorks.c -lauto -l/2011a/ -o guis:g4t11b
gcc: GuiGetIFceWorks.c: No such file or directory
8.Amiga OS 4:S> gcc GuiGetIFceWorks.c -lauto -l/2011a: -o guis:g4t11b
gcc: GuiGetIFceWorks.c: No such file or directory
8.Amiga OS 4:S> gcc GuiGetIFceWorks.c -lauto -l/2011a:/ -o guis:g4t11b
gcc: GuiGetIFceWorks.c: No such file or directory
8.Amiga OS 4:S> gcc GuiGetIFceWorks.c -lauto -l/guis:Dev/G4C_2011a/ -o guis:g4t11b
gcc: GuiGetIFceWorks.c: No such file or directory
maybe it works with the fullpath? but that would make the lines still longer
I tested combinations
8.Amiga OS 4:S>gcc 2011a:GuiGetIFceWorks.c -lauto -l/2011a:/ -o guis:g4t11b
8.Amiga OS 4:S> gcc 2011a:GuiGetIFceWorks.c -lauto -l/2011a: -o guis:g4t11b
8.Amiga OS 4:S> gcc 2011a:GuiGetIFceWorks.c -lauto -l/2011a/ -o guis:g4t11b
All three don't recognise the includes in 2011a:
Re: gcc does not recognise local headerfiles any more
Posted: Fri Oct 14, 2011 10:20 am
by Slayer
why not use the combination option of -print-search-dirs and tweaking -B <directory> to find a happy and hopefully working medium/solution?
If that does help does --sysroot=<directory> have any potential application?
Also, perhaps the answer lies with unix paths and having to drop into sh and not mixing volume references?
Just thinking out loud

Re: gcc does not recognise local headerfiles any more
Posted: Thu Oct 20, 2011 10:18 am
by JosDuchIt
@slayer thanks, but
gcc 2011a:GuiGetIFceWorks.c -B 2011a: -lauto -o guis:g4t11b does not recognise the header files
using --sysroot will probably make the system headers unavailable
I am using KCon or normal shell : maybe that is the problem?
I tend to believe that it is a weakness in using assigns (are these known to un unix?) and translating them internally (in OS4 compatible gcc) to their fullpaths
I could do that translation in my gcc interface, i am using. (written in Gui4Cli)
Anyway for now i just assign the directory one level higher than the one containing the file to compile and this works.