Lee Rhodes wrote: > Thank you! Your explanations clear and thoughtful and I am learning a lot. > > The documentation I had about dependencies and even cygwin's > package-picker did not give me any clues as to which of the dependencies had > devel/run split packages and which ones did not. In fact "cygcheck -c" > mislead me to believe that I had installed what was required. Well like I said this is the common packaging convention used on nearly all *nix distros too, so you'd have had an identical experience there if you lacked a missing -devel prerequisite package. Setup and cygcheck are only designed to deal with runtime dependencies, not build-time; and in that sense they were entirely correct, you had everything installed necessary to *run* the gcc package. The entire point of separating these two concepts is to save the average user from requiring many megabytes of files that are useless to them, with the implicit assumption that people who would build software from source are outnumbed by users who just install binary packages by some enormous ratio. And there's also the problem I already hinted at with multiple versions of a library, a requirement that comes up when an ABI changes and you don't want to have to recompile an entire distro. You pretty much have to separate packages into runtime and build-time portions in order to support versioned libraries, because you can generally only have one set of headers installed[*] but you can have many copies of the runtime. So it would be a huge backwards step in terms of binary compatibility if packages were not split this way, and in fact this is a major reason why it's done like this. Some *nix packaging systems like RPM and deb/apt have the ability to also specify build-time dependencies, but these are only useful when you build from a SRPM or specially prepared source package. In the case of downloading a regular tarball of source code and trying to build it they have no effect, you still have to know which -devel packages are required. And in fact Cygwin has this too, but not in an automated form. Every binary package is supposed to have a Cygwin-specific README that lists all build-time package requirements. You can find them in /usr/share/doc/Cygwin/*-README. In this case, gmp and mpfr were not even used by gcc 3.x so consulting the file wouldn't have told you that you needed them, just as having a gcc-3.4 SRPM would have been useless in your case. [*] You can obviously have multiple sets of versioned headers too, but to support this either the library has to be designed that way from day one, or you have to install to totally separate prefixes and then play games setting a bunch of -I and -L options in CFLAGS/CXXFLAGS/LDFLAGS which gets cumbersome and very ugly compared to just having one set in the system location which is how everything was designed to operate. > From CygWin's perspective, it would be useful if they had a GCC-Build > package that just selected all the right components. But that doesn't scale. Are we to offer a build-foo metapackage for every package? There would be hundreds, as this is in no way particular to gcc -- almost every package has a number of dependent libraries whose headers must be installed prior to being able to build them. Besides, it would just be replicating the information that is already there in the form of the Cygwin-specific README, with the same exact problem, namely that any 'gcc-build' metapackage would have to be in sync with the gcc packages offered and thus it would have reflected the requirements to build gcc 3.4 which did not even use gmp/mpfr. In that sense it is a generic problem common to any packaging system when you try to do something outside of its bounds. What it all comes down to is that when building something from source you take on the role of developer, which comes with a higher level of responsibility. Brian
