| |||||||||||||
you do NOT need to write all your programs together to make them work together.you do NOT need to write all your programs together to make them work together.Posted Jan 29, 2013 20:35 UTC (Tue) by khim (subscriber, #9252)In reply to: you do NOT need to write all your programs together to make them work together. by nix Parent article: Poettering: The Biggest Myths
But neither of the constraints you suggest are true, not even slightly. This may be true right now, today, but that's because there are no need to change anything rapidly (last major architecture was x86-64 and it was introduced years ago). When new platform is introduced you see things like "Binutils 2.16.91 or newer are required" quite regularly. And things often breaks even if these requirements are not written explicitly. We'll see how AArch64 will affect all that - but I doubt it'll be possible to use binutils "2.19 or something, maybe even older" for that. P.S. Note: I'm not saying it's somehow bad that it's done that way. In fact that's the right thing to do. But if GLibC is tightly tied GCC and GCC is tightly tied to binutils then why pretend that they are different projects? They are not: they are parts of larger project: GNU.
(Log in to post comments)
you do NOT need to write all your programs together to make them work together. Posted Jan 30, 2013 16:24 UTC (Wed) by nix (subscriber, #2304) [Link]
Well, yes, of *course* if a new architecture is introduced then you have to use a toolchain new enough to support that architecture! That doesn't mean that all projects that know about that architecture are the same project! Nor does it suddenly imply a tight tying among the projects.
Even among the toolchain-related projects, they have some different maintainers (though some in common), different governance structures, different mailing lists, different release schedules, different source trees and not much shared code infrastructure (the only bits I can think of shared between GNU toolchain components are libiberty and libbfd, though the latter is quite sizeable).
you do NOT need to write all your programs together to make them work together. Posted Jan 31, 2013 22:52 UTC (Thu) by khim (subscriber, #9252) [Link] Even among the toolchain-related projects, they have some different maintainers (though some in common), different governance structures, different mailing lists, different release schedules, different source trees and not much shared code infrastructure (the only bits I can think of shared between GNU toolchain components are libiberty and libbfd, though the latter is quite sizeable). This is true but I'm interaction with these people enough to notice that despite all that development happens in all these projects simultaneously. When you need to add, e.g. something like ifunc you need to change GLibC, binutils, and GCC in a lockstep - and this is done by the same people without regard to any other projects. To me it looks more like a large single project which is complicated by artificial division between glibc/binutils/gcc rather then three separate project: you still need to introduce changes in all these places but additionally you need to write code which will detect version skew and disable these features appropriately. The division lies at the different level: in GCC there are few layers (SSA, RTL, etc) and developers who work with different layers know less about other layers then "low-level GCC people" know about binutils and glibc!
you do NOT need to write all your programs together to make them work together. Posted Feb 2, 2013 19:17 UTC (Sat) by nix (subscriber, #2304) [Link]
All you say there is true -- some changes must affect several layers at once. However, a lot of changes affect glibc and the kernel at once, too -- does that mean that glibc and the kernel are the same project? (Note that for quite a long time the founder and co-maintainer of glibc was also one of the maintainers for one of the nastiest parts of the core kernel, ptrace() and signal handling, so even the people-in-common rule is true!)
I don't think they're the same project -- and neither are the various toolchain projects the same project, anymore than gnulib is the same project as coreutils merely because changes to both often happen in synchrony. They are simply projects with *some* close coupling between them -- but even that coupling is optional (you can build GCC and perhaps even glibc with a binutils that doesn't support IFUNC, and nothing goes wrong).
|
|||||||||||||