Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

For demo purposes, here is my one line program test.c :

#include <dbus/dbus.h>

This is my makefile :

INC     =   -I/usr/include/dbus-1.0         \
            -I/usr/lib/dbus-1.0/include

test    :   test.c
            gcc $(INC) -c -o test.o test.c

I have the dbus devel packages installed on both my Mer Linux (via zypper) and Cygwin (via the setup program). dbus/dbus.h are visible on both systems (ls /usr/include/dbus-1.0 shows the folder dbus containing the file dbus.h among many). This compiles successfully on Mer Linux, but when compiled on Cygwin (2.831 64-Bit running on Win 7), I get the follow error:

test.c:1:23: fatal error: dbus/dbus.h: No such file or directory
 #include <dbus/dbus.h>
                       ^
compilation terminated.
makefile:5: recipe for target 'test' failed
make: *** [test] Error 1

I've tried every simple variant I can think of to make Cygwin work - space between -I and path, extra slash on end of path, different orders of the gcc arguments. Nothing simple seems to remedy this problem which shouldn't exist.

Help!

share|improve this question
    
Does the compile command line work if you don't use the makefile? –  Greg Hewgill May 21 at 22:20
    
Install the Cygwin strace and run strace gcc -I/usr/include/dbus-1.0 -c test.c and post the resulting trace. –  Gilles May 22 at 0:14
    
Compiling form the command line using the same arguments produces the same error message from gcc less the error messages from make. –  Greg Young May 22 at 5:57
    
I've run setup-x86_64 for Cygwin, but when searched, I see no package named "strace". –  Greg Young May 22 at 5:57

1 Answer 1

A Stack Overflow comment discusses the possibility of this being due to having a version of gcc or make that isn't dealing with the unix/Windows path style conflict. A similar problem was had in another situation, which was resolved by ensuring that Cygwin's version of gcc was installed as it was otherwise falling back on something else.

If you do not have the canonical Cygwin gcc/make installed, this may be the cause the problem.

share|improve this answer
1  
In other words, if which gcc doesn't show /usr/bin/gcc or /bin/gcc, you need to either install Cygwin's gcc-core package, or fix your $PATH. –  Yaakov May 22 at 4:41
    
When I run inline where gcc, it tells me C:\MinGW\gcc.exe. I forgot I installed MinGW (gcc is 4.8.1) and am not using Cygwin default gcc.exe - a fact that might have been useful. /cygdrive/c/MinGW/bin is on my PATH (as evidenced by the where command). So it's a potentially different compiler than I reported, but the problem still seems to violate way the -I argument and #include are suppose to work together. –  Greg Young May 22 at 6:13
1  
@GregYoung That's definitely the problem then. You have the MinGW version of gcc (which uses Windows path names), and are expecting that to work with Cygwin path names. It won't. You will need to either: (a) change your -I options to use Windows path names like MinGW-gcc expects, or (b) use the Cygwin build of gcc. –  Greg Hewgill May 22 at 20:53
    
@GregHewgill That was it! Thanks! Not only does MinGW use Windows paths, but Cygwin installs the DBus headers in different locations. So my new makefile, which works both with Cygwin/MinGW and Mer/gcc, has separate INC defines based on ifeq ($(OS),Windows_NT) to detect Cygwin/MinGW. –  Greg Young May 23 at 3:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.