Mail Archives: cygwin/2007/06/17/11:02:53
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/
- Raw text -