This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: included headers with mno-cygwin

On 14 Nov 2000, at 18:54, the Illustrious Tilman Utz wrote:

> Paul Garceau schrieb:
> >
> > > What I discovered until now:
> > > - I passed the -H option to the compiler to see what headers
> > > are included. The output file is about 1.57 MByte large and I
> > > couldn't read everything so far, but at a first glance, I saw
> > > the following headers repeatedly being included:
> > >
> > >
> > > /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-4/../../../../include/
> > > g++- 3/iostream.h
> >
> >         Here are the most immediate problems I can see:
> >
> >         /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-4, unless there
> >         is a
> > symlink of some sort somewhere else, is no longer referenced by
> > Cygwin.  I base this statement on the observation that the
> > latest installation (setup.exe from does
> > not create any such directory/folder on a fresh install.
> >
> >         Not sure if this is because of original version you are
> >         using
> > or not.  However, you might want to delete your cygwin
> > directory/folder and start with a fresh install.  I don't know
> > if the latest setup handles this...DJ?
> err, strange thing, I installed my current version of cygwin on
> November 9th from the freesoftware mirror... but I can try
> again...

	There has been at least one update since then that I am aware 
of.  At any rate.  The setup.exe, apparently, is not smart 
enough to change the currently existing directory structure in 
order to accomodate the latest directory structure layout for 
Cygwin install (ie delete directories that no longer exist).
	Or, if setup.exe is smart enough to change directory structure, 
it is not updating the system registry in order to accomodate 
the latest directory structure by eliminating any registry 
references to /usr/lib/gcc-lib/i686-pc-cygwin/...

	Thus my suggestion to delete your current cygwin directory, and 
then re-install Cygwin from scratch.

> > > So i think
> > > they shouldn't be included. The following seems to me as a
> > > logical consequence of the above:
> > >
> > > - objdump -p executable-name | grep "DLL Name" produced the
> > > following result:
> > >                      DLL Name: KERNEL32.dll
> > >                      DLL Name: cygwin1.dll
> > >                      DLL Name: crtdll.dll
> > >       or is ist ok, that it uses cygwin _and_ crtdll?
> >
> >         Yes, that is the only way it works for -mno-cygwin
> > compile/linking.
> but I thought, using the cygwin flag I wouldn't link against
> cygwin1.dll

	Actually, using the "-mno-cygwin" switch _does_ bypass linking 
against cygwin1.dll.
	"Not using" the "-mno-cygwin" switch defaults to linking the 
cygwin1.dll, ie. if you do not use"-mno-cygwin" switch, the 
default behaviour of g++/ld for Cygwin is to link cygwin1.dll.  
crtdll.dll is, generally speaking, only linked if you 
use/set/enable the "-mno-cygwin" switch.

> >
> > >
> > > So, what I'd like to ask: If the above headers aren't mingw,
> > > where may I get the corresponding mingw headers?
> >
> >         Afaik, the the .dlls you reference are provided by MS
> >         as part
> > of any MS OS distribution and, individually, need to be
> > referencable by the linker.
> >
> > > How can I make
> > > the makefile not include cygwin<1.dll> headers?
> >
> >         As you did earlier, simply compile with -mno-cygwin.
> > crtdll.dll and Kernel32.dll are required for win32api based
> > builds using either cygwin or mingw.

	Correction, crtdll.dll is only required for -mno-cygwin builds. 
 Please forgive any confusion this may have created.

> >
> >         If you need to build a mingw c++ app then,  for now,
> >         you would
> > probably be better off downloading mingw-msvcrt distribution
> > and then adding the g++ libs (g++-v3, as a general behavioural
> > rule, works fine for mingw after you build and install the
> > g++-v3 libs...

	 using mingw.)

	Afaik, g++-v3 libs will not work for mingw if they have been 
built using cygwin1.dll (Cygwin).

>         Sorry, that, I don't understand. Do you mean I should
>         switch from
> cygwin to mingw, if I want cygwin-dll independent executables
> (that's what I intend), or just install the 'right' headers and
> libs, which are included in the mingw distribution?

	Actually, I mean that if you want to use c++ for a mingw build, 
you should use mingw.  Mingw has no reliance on cygwin1.dll.

	If you want to use Cygwin for C++ build then you shouldn't use 
the -mno-cygwin switch.  Cygwin built C++ libraries require 

>         I probably didn't make myself clear. I have this library,
>         sources
> with a makefile (actually this is generated by a configure
> script), which needs for whatever reasons to be compiled with the
> gcc. As I intend to write an application for win32, I tried to
> compile the lib with the mno-cygwin flag, to become independent
> of cygwin.dll. I suceeded building the library under cygwin
> without the flag, so the makefile seems to be ok...

	Ok, so you know the makefile actually works.  All that is left 
to understand, then, is the methods used to compile and link the 
application in question (see my comments above re: differences 
between "using -mno-cygwin" and "not using -mno-cygwin").

>         Now I'm struggling hard to make the same with the flag,
>         which
> isn't easy, especially as I'm a 'newbie' on C++ and all the
> Unix-cygwin-win32 stuff.

	No problem...Welcome to the world of Gnu Development!


		Paul G.

Nothing real can be threatened.
    Nothing unreal exists.

Want to unsubscribe from this list?
Send a message to

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]