This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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] | |
>> Note that any dependencies between modules must be explicitly >> specified via Makefile dependencies now. Please do not rely on the >> order that they're listed - I can pretty much guarantee that that >>will NOT work any more. > >Right, of course. > >Well, I guess I need to figure out where that loop was and whether we >can break it some other way. I'd really like libiberty to be built >after newlib. My patch *does* that, correctly, via the change from all-target-libiberty: $(ALL_GCC) to all-target-libiberty: $(ALL_GCC_C) The dependency loop was caused by serialization dependencies, as so: (explicit) configure-target-libiberty: all-target-newlib (normal) all-target-newlib: configure-target-newlib (serialization) configure-target-newlib: configure-target-libiberty The reordering causes the reordering of the serialization dependencies so the third dependency doesn't appear. -- This could still work if cygwin configuration depends on libiberty configuration, since we will then have to add an explicit dependency such as: configure-target-winsup: all-target-libiberty But this is OK; it means that newlib is configured, then built, libiberty is configured, then built, and then winsup is configured, then built. (Odd, admittedly.) But Cygwin doesn't really have a C library to link to until winsup is built, so probably the link tests will fail when linking to newlib ~sans~ winsup. If they succeed, of course, my above plan would actually work.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |