Mail Archives: cygwin/2000/03/31/11:11:51
Jimen Ching <jching AT flex DOT com> writes:
>
> I wrote a program that uses the cygwin UNIX layer. I need to link this
> application to a library that was written for Win32.
>
> My program compiles with cygwin, no problems. When I tried to compile the
> library using cygwin, it includes io.h and wants the 'access' function
> prototype. But io.h (non-mingw32 version) has almost nothing in it.
And it shouldn't. It's a platform specific header, and is not required
to have anything more than what's needed for *that* platform.
> I'm compiling the source of both without the mingw32 option. Thus, gcc
> does not look into the mingw32 header directory. Am I supposed to compile
> the library using mingw32, and my program with non-mingw32? I was under
> the impression that I can write an application that uses both the Win32
> API _and_ the cygwin UNIX layer. But the header files seem to stand in
> the way...
I do this all the time, and just do the right thing depending on the
platform. Most of my code is configure driven, so it's a bit different,
but the basic idea is the following:
/* Get access() prototype. */
#ifdef __MINGW32__
# include <io.h>
#elif HAVE_UNISTD_H
# include <unistd.h>
#else
# /* do something to declare access() on systems that lack unistd.h.
#endif
Where HAVE_UNISTD_H is probed for by configure. If you know your target
Unix/Cygwin system already has unistd.h, you can always do the following:
/* Get access() prototype. */
#ifdef __MINGW32__
# include <io.h>
#else
# include <unistd.h>
#endif
Regards,
Mumit
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -