This is the mail archive of the cygwin-patches 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] |
DJ Delorie wrote: > IIRC, that whole clause was because cygwin's dll itself linked with > libiberty, so the auto-detect stuff needed an override to make sure > the right files were there when you build cygwin1.dll. Otherwise, it > would detect that cygwin had strsignal, not build it, then fail later > when cygwin1.dll couldn't find strsignal. > > If cygwin no longer links with libiberty, that whole clause can > probably go away now. As it's target-specific, I'm OK with letting > the target maintainers have the last word about it, too. There are no longer any references to ../libiberty/* in Cygwin's Makefile, and indeed the libiberty subdir has been removed from the module definition for winsup so you don't even get it in a fresh checkout any more. Given that, I think we can remove the clause entirely. I've tested this by doing (separate) native builds of GCC, winsup, binutils and GDB, with no issues arising. I haven't tried cross-builds or combined source-tree builds, but there's no reason to believe they would be affected any differently. GCC is in stage 4, but this is target-specific and fixes a bootstrap failure on a secondary platform. Ok for HEAD of both gcc/ and src/ ? libiberty/ChangeLog * configure.ac (funcs, vars, checkfuncs): Don't munge on Cygwin, as it no longer shares libiberty object files. * configure: Regenerated. cheers, DaveK
Attachment:
libiberty-cyghack-removal-patch.diff
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |