gcc does not recognise local headerfiles any more

[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

[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.

[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:

[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

[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.