X-Spam-Check-By: sourceware.org
Message-ID: <46754D06.EF4257C6@dessent.net>
Date: Sun, 17 Jun 2007 08:02:30 -0700
From: Brian Dessent <brian AT dessent DOT net>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Some notes on building gcc-4.3.0
References: <466F9B52 DOT 1000709 AT cwilson DOT fastmail DOT fm> <4672C1F4 DOT 6010306 AT users DOT sourceforge DOT net> <46736405 DOT 2010303 AT cwilson DOT fastmail DOT fm> <4673E461 DOT 80960A59 AT dessent DOT net> <4674D739 DOT 9080006 AT cwilson DOT fastmail DOT fm>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Charles Wilson wrote:

> > Are we really going to tell them that there is no choice in the matter,
> > that if they want cross-.so EH they must suffer shared libraries?
> 
> Yes.  Microsoft does the same thing.  They just have an inside advantage
> in supplying their runtime with the OS.
> 
> > They
> > will probably complain that they could get what they wanted from gcc 3.4
> > and will likely continue to use that version.
> 
> Ok.  That doesn't worry me.

Well, after all, WJM.

> Sadly, probably so.  And it's worse than you know: because libgcc is not
> built using libtool, it doesn't benefit from libtool's knowledge that
> DLLs on cygwin should be called cyg*.dll.  Thus, unless changes are
> made, both mingw and cygwin will ship "libgcc_s.dll" files that users
> will want to put in their $PATH -- only one relies on cygwin1.dll and
> the other on msvcrt.dll.

Yucko.

> See above.  Don't despair; it's not as dire as it sounds.  The trunk
> *currently* doesn't build libgcc_s.dll with the special cyg* prefix --
> because nobody has built it shared at all on win32, so the problem of
> conflicting with mingw hasn't come up.  Teaching the build system about
> the cyg prefix is actually a fairly simple change.
> 
> The other is part policy, part implementation: suppose cygwin (or mingw)
> ships both a dwarf2 and a sjlj compiler.  Each one will provide runtime
> dlls (libgcc_s, but also the libtool-built runtimes libstdc++,
> libsupc++, libgfortran, etc etc).  Under normal circumstances, you'd use
>   a different build/host/target:
>    configure target=i686-pc-cygwin-dw2 build=...dw2 host=...dw2
> so they'd each get installed in separate directories.  However the dlls
> need to go into the main /bin/ so users can have a simple PATH -- so the
> DLLs need different names.
> 
> That is, the dll names need to be sensitive to the target= specifier --
> even tho the static libs and import libs should maintain their
> "standard" names (otherwise we have to muck with the spec files and make
> a lot of other intrusive changes).
> 
> So, you might have:
>     cyggcc_s_dw.dll     << i686-pc-cygwin-dw2/4.3.0/libgcc_s.dll.a
>     cyggcc_s.dll (sjlj) << i686-pc-cygwin/4.3.0/libgcc_s.dll.a
> 
>     cygstdc++-6_dw.dll << i686-pc-cygwin-dw2/4.3.0/libstdc++.dll.a
>     cygstdc++-6.dll    << i686-pc-cygwin/4.3.0/libstdc++.dll.a
> 
> etc.  In the libgcc case, we have to play games in libgcc/config/.  In
> the latter case...we need a new libtool/automake feature, I think.

I had noticed that Danny has been using --target=mingw32dw2 for his
Dwarf2 builds so that they could be installed in parallel to the
standard ones, so yes this sounds very sensible.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/