mingw-users

[Mingw-users] Conflict with included header directories

[xlabscat <xl...@ho...>]

After trying for some days looking for any light about this problem on
various forums I guess its time to ask: 
 
I have various directories in my include path. I feed them to the compiler
using the -I<dir> option. 
One of these directories is called "/bla/algorithm" with someheader files
inside. 
This library I include by adding "-I/bla" to my compiler flags. 
 
If I try to include the std algorithm header with the same name in any file 
 
#include <algorithm> 
 
gcc will see my /bla/algorithm directory as a match. Gcc thinks that
"/bla/algorithm" is a file and it will 
fail opening it of course, reason for the compiler to not find anything
inside the original std algorithm. 
Cygwin doesn't show any problem with this. 
 
I know I could change "-I" and use "-iquote" instead and change the hundreds
of files of the libs I use, but it stays a bug. 
 
You can reproduce the bug with this 
 
- create a file with inside: 
#include <map> 
- at the same directory, create a new directory named "map" 
- compile the file including your map dir path 
gcc -I. (map dir and your file are at the same path of course) 
 
I hope anyone could have any solution to this problem or give any tip. 
Thanks. 
 
-- 
View this message in context: http://www.nabble.com/Conflict-with-included-header-directories-tp15105322p15105322.html
Sent from the MinGW - User mailing list archive at Nabble.com.

Re: [Mingw-users] Conflict with included header directories

[Greg C. <gch...@sb...>]

On 2008-01-26 10:00Z, xlabscat wrote:
[...]
> You can reproduce the bug with this 
>  
> - create a file with inside: 
> #include <map> 
> - at the same directory, create a new directory named "map" 
> - compile the file including your map dir path 
> gcc -I. (map dir and your file are at the same path of course) 

Not reproduced here. Does the following fail for you?

cd /tmp
rm -rf map
mkdir map
cat >map_test.cpp <<"EOF"
#include <map>
int main(){}
EOF
/MinGW_/bin/g++ -I. map_test.cpp

/MinGW_/bin/g++ --version
g++.exe (GCC) 3.4.4 (mingw special)

Re: [Mingw-users] Conflict with included header directories

[xlabscat <xl...@ho...>]

Yes, but Im affraid I forgot to mention my system characteristics in the
original post, My apologizes:

I have compiled a cross compiler using the 4.2.1 version as the build system
namely,
I downloaded the 4.2.2 gcc source and compiled it with 4.2.1 (compiled
binutils first of course), this with i686-elf as target.

if I use the 4.2.1-sjlj for the example I mentioned, then I get no problems,
but if I use the compiler that I compiled, 4.2.2 i686-elf, then I get the
problem. Like I said, if I rename the conflicting dirs and all references
inside the files then I have no conflict at all. My project is made of
almost thousand files filled with stl, boost stuff that runs in a self
developed rtos(newlib of course). The resulting binary works like a charm so
Im sure the binutils and gcc/newlib I generated are fine, its just that in
my libraries I cant use any directory name that has the same name as the
files in the default system includes.

So in resume yes; If I type exaclty what you posted then I get 
test.cpp:1 ./map Permision denied

because it finds the entry "map" and it thinks it is a file. -I puts the
refered path at the front of the list of paths to look for system include
files. Nothing wrong with it, its just that my "map" is a dir and not a
file.


Thank  you guys for your replies.

-- 
View this message in context: http://www.nabble.com/Conflict-with-included-header-directories-tp15105322p15111948.html
Sent from the MinGW - User mailing list archive at Nabble.com.

Re: [Mingw-users] Conflict with included header directories

[Earnie B. <ea...@us...>]

Quoting xlabscat <xl...@ho...>:

>
> After trying for some days looking for any light about this problem on
> various forums I guess its time to ask:
>
> I have various directories in my include path. I feed them to the compiler
> using the -I<dir> option.
> One of these directories is called "/bla/algorithm" with someheader files
> inside.
> This library I include by adding "-I/bla" to my compiler flags.
>
> If I try to include the std algorithm header with the same name in any file
>
> #include <algorithm>
>
> gcc will see my /bla/algorithm directory as a match. Gcc thinks that
> "/bla/algorithm" is a file and it will
> fail opening it of course, reason for the compiler to not find anything
> inside the original std algorithm.
> Cygwin doesn't show any problem with this.
>
> I know I could change "-I" and use "-iquote" instead and change the hundreds
> of files of the libs I use, but it stays a bug.
>
> You can reproduce the bug with this
>
> - create a file with inside:
> #include <map>
> - at the same directory, create a new directory named "map"
> - compile the file including your map dir path
> gcc -I. (map dir and your file are at the same path of course)
>
> I hope anyone could have any solution to this problem or give any tip.
> Thanks.
>

Would this work on say Linux for instance?  While I suppose one could 
say that GCC should not try to open a directory for an include file the 
fact is a directory is nothing more than a file.  Does g++ emit the 
same issue as gcc?  G++ is the C++ compiler frontend and it may know to 
check that algorithm is a directory.  BTW, -I has precedence in finding 
the header files; so, if your library includes a file with the same 
name as a system file then you out of luck and need to rename your 
library file.

Earnie

Re: [Mingw-users] Conflict with included header directories

[xlabscat <xl...@ho...>]

I couldnt tell because All my development takes place in visual studio 2005
as IDE and gcc as compiler.

I just updated the main post with the specifics of my toolchain.

the reason from moving to mingw from the cygwin thing is the file
performance, mainly because my precompiled header is a big one (40-50MB
.gch). Mingw finishes my project in 4 minutes in a quad core machine while
cygwin takes almost 15. Im using -j8 as option for make so I can see the
cores at 100%.

-- 
View this message in context: http://www.nabble.com/Conflict-with-included-header-directories-tp15105322p15112257.html
Sent from the MinGW - User mailing list archive at Nabble.com.

Re: [Mingw-users] Conflict with included header directories

[Danny S. <dan...@cl...>]

> -----Original Message-----
> From: min...@li... 
> [mailto:min...@li...] On Behalf 
> Of Earnie Boyd
> Sent: Sunday, 27 January 2008 8:25 a.m.
> To: min...@li...
> Subject: Re: [Mingw-users] Conflict with included header directories
> 
> 
> 
> Quoting xlabscat <xl...@ho...>:
> 
> >
> > After trying for some days looking for any light about this 
> problem on
> > various forums I guess its time to ask:
> >
> > I have various directories in my include path. I feed them 
> to the compiler
> > using the -I<dir> option.
> > One of these directories is called "/bla/algorithm" with 
> someheader files
> > inside.
> > This library I include by adding "-I/bla" to my compiler flags.
> >
> > If I try to include the std algorithm header with the same 
> name in any file
> >
> > #include <algorithm>
> >
> > gcc will see my /bla/algorithm directory as a match. Gcc thinks that
> > "/bla/algorithm" is a file and it will
> > fail opening it of course, reason for the compiler to not 
> find anything
> > inside the original std algorithm.
> > Cygwin doesn't show any problem with this.
> >
> > I know I could change "-I" and use "-iquote" instead and 
> change the hundreds
> > of files of the libs I use, but it stays a bug.
> >
> > You can reproduce the bug with this
> >
> > - create a file with inside:
> > #include <map>
> > - at the same directory, create a new directory named "map"
> > - compile the file including your map dir path
> > gcc -I. (map dir and your file are at the same path of course)
> >
> > I hope anyone could have any solution to this problem or 
> give any tip.
> > Thanks.
> >
> 
> Would this work on say Linux for instance?  

Yes.  It is fixed for mingw32 on trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11242
Danny

Re: [Mingw-users] Conflict with included header directories

[xlabscat <xl...@ho...>]

So you think that the fast way is to apply the same patch to the 4.2.2
sources and rebuild the toolchain?
At the other hand, Im happy to know it is a known issue.

Thanks for your finding.
-- 
View this message in context: http://www.nabble.com/Conflict-with-included-header-directories-tp15105322p15112004.html
Sent from the MinGW - User mailing list archive at Nabble.com.