On Wed, Nov 06, 2002, David Brownlee wrote: > Yes, I'm assuming that to have true control over the build environment, the > only development tools used to build binary RPMs on the OpenPKG 1.1 ISO > image were the tools provided in the OpenPKG 1.1 (gcc, binutils, etc). > This leads to a "chicken and egg" problem but, I assumed that once the > original GNU development tools were built using Solaris development tools, > the resulting GNU tools were used to rebuild themselves without the Solaris > tools and this can be repeated. I guess that is my idea of a self hosting > environment. From that point on, no native Solaris tools were used to > build binaries for any other packages such as samba or apache. I do > recognize that I still need to to have the system header files (SUNWhea) on > the development host an any system libraries (such as SUNWlibm and SUNWlmx) > installed on both development and production hosts. > That's right. The goal with OpenPKG is a (almost totally) self hosting environment as you describe. Bootstrapping from a zero state will always require some special technique such as using binary packages or the Solaris native delevopment environment. However, your two phase idea is the cleanest way and should work very well. If not, then there is a bug somewhere that I don't know about. The requirements to bootstrap OpenPKG from either a source or binary package are documented in:
http://www.openpkg.org/doc/handbook/openpkg.html#bstrap-sfware > [...] > I want to rebuild everything, > including gcc, binutils, etc., but according to the test with pdflib and > samba, I'm afraid I would be building everything with a dependency on Sun's > ld and not the ld in the binutils package. Should this be logged as a bug > in the build of the gcc binary RPM? > I don't think so. The tools 'ld', 'nm', 'ar', 'as', and 'cc' are implicit requirements of many OpenPKG packages. If these tools are served by a OpenPKG instance or some other non-native means is perfectly fine. However, if building 'ld' dependent packages uses a 'ld' that you don't prefer (or doesn't exist) then there must be a reason for this logic. I suspect that your build of gcc is at fault, as it hardcodes the path to 'ld' and then uses it in later even if you install another ld somewhere else. It should be clear if my suspicion is true once you try rebuilding gcc *after* installing binutils *and* using the 'with_binutils' option. > This was my next step. I did not know about the switches so I was going to > leave /usr/ccs renamed to /usr/ccs.save. I think my next attempt will use > the switches you suggest and I will leave /usr/ccs in its renamed state > just in case. Due to time zone differences, I think I will be able to tell > you how it went before you read this reply. > It would be much more satisfying if it all worked without renaming /usr/ccs.save. In any case, /usr/ccs is where some required software resides (like 'ld' and 'nm' when building binutils), so I wouldn't leave it that way. Good luck, Michael -- [EMAIL PROTECTED] Development Team, Application Services Cable & Wireless Deutschland GmbH
msg00182/pgp00000.pgp
Description: PGP signature
