Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Message-ID: <38E0DB8E.4FF8B722@vinschen.de>
Date: Tue, 28 Mar 2000 18:19:26 +0200
From: Corinna Vinschen <corinna AT vinschen DOT de>
Reply-To: cygwin-developers AT sourceware DOT cygnus DOT com
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U)
X-Accept-Language: de,en
MIME-Version: 1.0
To: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: net release/installer status?
References: <38E01318 DOT 5EA4BD9 AT vinschen DOT de> <200003280434 DOT WAA18089 AT hp2 DOT xraylith DOT wisc DOT edu> <20000327234123 DOT A26568 AT cygnus DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Faylor wrote:
> 
> On Mon, Mar 27, 2000 at 10:34:41PM -0600, Mumit Khan wrote:
> >Corinna Vinschen <corinna AT vinschen DOT de> writes:
> >>FYI: I finally could cross compile cygwin1.dll on my linux box.  Ah,
> >>yes, it's not only compiled but it also runs under W2K.
> >>
> >>Nevertheless I have some trouble.  I have patched two Makefiles and I
> >>had to configure twice in winsup.  Eventually I couldn't compile the
> >>utils subdir because w32api/include isn't in the configured incude path
> >>list.
> >
> >The problem may actually be quite simple -- we may be lacking -nostdinc
> >-I<path_to_w32ap_include> in the Makefiles.  The -B<path_to_newlib>
> >only handles the newlib includes, but the w32api headers are still
> >coming from your installed tree.
> 
> There *is* a -I<path_to_w32ap_include> in winsup/Makefile.common:
> [...]

I was somewhat tired that night. The above missing include path to
w32api/include doesn't occur in winsup/utils but in winsup/cygwin
when compiling cygrun.exe. I think I have found the terrorist:
In winsup/cygwin/Makefile.in:

=== SNIP ===
cygrun.exe : $(srcdir)/cygrun.c $(DLL_IMPORTS) $(w32api_lib)/libuser32.a
\
             $(w32api_lib)/libshell32.a
        $(CC) -o $@ -L$(w32api_lib) $(srcdir)/cygrun.c
=== SNAP ===

I have substituted $(CC) by $(COMPILE_CC) and it works fine.

> Or is Corinna referring to the top-level utils directory?

No, I was blind only... my eyes were lying in bed already.

> I did submit a patch to include the various include directories when
> building gcc:
> 
> LIBGCC2_INCLUDES = -I$(srcdir)/../winsup/include \
>         -I$(srcdir)/../winsup/cygwin/include \
>         -I$(srcdir)/../winsup/w32api/include
> 
> This is in the sourceware gcc.

This isn't in the net release preview, AFAICS. It's the one I've
downloaded.

The other problem:
The top level Makefile.in missed the "$$s/winsup/include" path
in CC_FOR_TARGET and CXX_FOR_TARGET.
This is due to the fact that I've used Makefile.in from the
binutils-src out of the net release preview. The top level
Makefile.in of the winsup cvs directory on sourceware is correct,
either.

Another problem: The directories $(toplevel)/include and/or
$(toplevel)/libiberty (I'm not sure yet which one is the problem)
are different between those included in binutils-src-19990818.1
and those included in the winsup cvs directory. I have to use those
from binutils to get gcc (and the other stuff) compiled.

Just now a new build from scratch is running on my linux box
where I have changed all of the above details. Let's see...

Corinna