This is the mail archive of the cygwin 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]
Other format: [Raw text]

Re: Some notes on building gcc-4.3.0

Charles Wilson wrote:

> > Are we really going to tell them that there is no choice in the matter,
> > that if they want 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.


> 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.


Unsubscribe info:
Problem reports:

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