Michael Schloh von Bennewitz wrote: > Why don't you think that pdflib is quite right, because of the > /usr/ccs/bin/ld issue?
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. With this assumption, I believe that if I have all the necessary headers and libraries (but not the development tools provided with Solaris), I should be able to: (Phase 1) - Install the OpenPKG 1.1 binary bootstrap using "sh openpkg-1.1.0-1.1.0.sparc64-solaris2.8-cw.sh" - Install the OpenPKG 1.1 binary RPM for gcc - Install the OpenPKG 1.1 binary RPM for binutils - Install the OpenPKG 1.1 binary RPM for make - Install the OpenPKG 1.1 binary RPMs for other tools like bison, flex, m4, etc. Once I have the OpenPKG binary RPMs installed, I believe that, to eliminate cross-machine problems and without using any Solaris tools, I should be able to: (Phase 2) - Rebuild the OpenPKG environment using "sh openpkg-1.1.0-1.1.0.src.sh" (possibly changing the users and root of the OpenPKG environment) - Rebuild all the OpenPKG development tools (gcc, binutils, make, etc.) from their SRPMs - Uninstall all RPMs, including openpkg, and reinstall using the binary openpkg-1.1.0-1.1.0.sparc64-solaris2.8-??.sh and RPMs built on this machine > I would reccommend that to rule out cross-machine problems you only > install binary packages which are built from the same machine. > I agree. That is what I want to do in phase two. I won't have a development environment on every machine but, the machines I'm concerned about are all Sun E250s built from a Jumpstart installation. > This seems to be our main problem now, and I have a suspicion. I believe > that when you install 'gcc', the path to 'ld' is hardcoded. I assume that > when you built your gcc package, there was no binutils package installed. > If you later install binutils, then the possibility exists that a > subsequent configure script will find the GNU ld (and not native Solaris) > and decide to append flags like '-E' which the native Solaris ld does not > support. I completed phase 1 and decided to test pdflib and samba first since those packages had problems in my old environment. That is when I noticed the dependency on Sun's ld. I have NOT started phase 2, rebuilding everything from SRPMs, yet (pdflib and samba were quick tests). If what you say about ld being hardcoded into gcc, then that is how OpenPKG 1.1 binaries are distributed (at least on the ISO image). 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? > Try removing the binutils package, and check that the GNU is gone by doing > 'which ld'. Try to look in places that samba's configure script would look > and make sure there is no GNU ld there. Then build samba again. I hope > that it will then not append the -E. Well, unless Sun is installing GNU ld as part of a clean "developer" installation of Solaris, there are no other instances of GNU ld. However, the -E is not the problem because I want to use ld from binutils. I would like everything in OpenPKG to be self-sufficient by using binutils. I do not want to put SUNWtoo (and maybe SUNWarc/SUNWarcx) on all my hosts because I have have build OpenPKG RPMs with dependencies on Sun tools. > If this doesn't work, you might try the GNU ld way: > > $ rpm --rebuild > ftp://ftp.openpkg.org/current/SRC/binutils-2.13-20020826.src.rpm > # rpm -Uvh path-to-binutils-XX-XX-sparc64-solaris2.8-cw.rpm > $ rpm --rebuild > ftp://ftp.openpkg.org/current/SRC/gcc-3.2-20020815.src.rpm --define > "with_binutils yes" > # rpm -Uvh path-to-gcc-XX-XX-sparc64-solaris2.8-cw.rpm > $ rpm --rebuild > ftp://ftp.openpkg.org/current/SRC/samba-2.2.6-20021017.src.rpm > # rpm -Uvh path-to-samba-XX-XX-sparc64-solaris2.8-cw.rpm > > If this is the way (and sequence) you installed binutils and gcc before > then it was correct the first time. Otherwise try it again, and pay > special attention to the --define argument when installing 'gcc'. There > should be no '=' inbetween 'with_binutils' and 'yes'. There are two other > such arguments for gcc, by the way: 'with_cxx yes' and 'with_optimize > yes'. 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. > I've personally never built that way 'su cw', but it seems like it should > work. I build as a normal user, from my home directory, and with a > .rpmmacros file. Things work very well that way, but choose whatever suits > your needs. I'm new to OpenPKG so I don't have any preferences other than to try to mimic the methodologies the OpenPKG developers. That way, if I have time to contribute spec files of my own, you will have the highest probability to duplicate my successes (and failures). If you use ~/.rpmmacros, so will I. Thanks for the suggestions, I will get back to you soon. ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List [EMAIL PROTECTED]
