Sorry for the long reply, I was trying to document a reproducible setup and started to ramble. The summary is I now suspect my environment. When you initially setup your dev hosts, did you start with a Solaris "user" or "developer" install?
Michael Schloh von Bennewitz wrote: [snip] > I kind of doubt that this is a RTFM problem, as Solaris is a pretty well > supported platform. It has long been in production use without paying > special attention to requirements (outside of a missing cc at bootstrap > time - which you have already gotten around). I just hope that your > machine did not meet with some unstandard hacks for some reason or was > very strangely installed, but I doubt that too. I wouldn't worry about the > stuff in /var/spool/pkg, but I assume that you did a pkgrm SFWtiff as well > as rpm -r tiff. Yes, I did remove SFWtiff with "pkgrm SFWtiff" and I don't think that there are any non-standard hacks on that host. However, I usually start with a "core" installation of Solaris with an additional handfull of packages from the installation media. Is that strange? It is a pretty Spartan setup and may be missing something critical. I tried your suggestions without luck (as described below). Since it is important to me to determine the OS requirements, I decided to start from scratch, i.e. start with a clean install of Solaris 8, on a different harddrive (also described below). I still have my original environment safe so, if this experiment introduced too many variables to troubleshoot, I can always swap the original disks back in. The responses to your suggestions were done on the original system. >> Script started on Wed Oct 30 07:46:28 2002 >> # rpm --rebuild >> # ftp://ftp.openpkg.org/current/SRC/pdflib-4.0.3-20021030.src.rpm >> Installing >> ftp://ftp.openpkg.org/current/SRC/pdflib-4.0.3-20021030.src.rpm >> Executing(%prep): env -i /opt/openpkg/lib/openpkg/bash --norc --noprofile >> --posix -e /opt/openpkg/RPM/TMP/rpm-tmp.24336 + cd /opt/openpkg/RPM/TMP >> + cd /opt/openpkg/RPM/TMP >> + rm -rf pdflib-4.0.3 >> + /opt/openpkg/lib/openpkg/gzip -dc >> /opt/openpkg/RPM/SRC/pdflib/pdflib-4.0.3.tar.gz >> + /opt/openpkg/lib/openpkg/tar -xf - >> [...] >> > > Otherwise as you see from your own script ScriptB, rpm unpacks into > > (1) /opt/openpkg/RPM/TMP/pdflib-4.0.3 > > on your machine (as it similarly does with all other OpenPKG packages). I > think that in the next level of troubleshooting, you should build the > package as usual: > > (2) # rpm --rebuild > ftp://ftp.openpkg.org/[...]/pdflib-4.0.3-20021030.src.rpm > > and then do something like: > > (3) # cd /opt/openpkg/RPM/TMP/pdflib-4.0.3 > (4) # cd tiff > (5) # /opt/openpkg/bin/make > > This is what I would do if I had access to your machine, to find out just > what is happening with the tiff library. Maybe it has nothing to do with > the native tiff pieces - try checking this by doing the above in another > subdirectory such as 'png', 'pdflib', or 'clients'. It looks like although > you have ruled out bash or ksh as problem sources, you are building as the > root user. Although this shouldn't be a problem, please try building (2) > as a normal user. Also do '# which rpm' to make sure you are not using > another rpm by accident. Building as a normal user (at least as myself) gives the following results: Installing ftp://ftp.openpkg.org/release/1.1/SRC/pdflib-4.0.3-1.1.0.src.rpm error: cannot create sourcedir /opt/openpkg/RPM/SRC/pdflib The reason is obvious when you look at the permissions on /opt/openpkg/RPM/SRC. If you can point me to documentation regarding how the OpenPKG user accounts are used, I would appreciate it. I'm still not sure what the intended use of each account is. Anyway, I did "su - openpkg" since that account has write access (openpkg being the equivalent to cw on this system) and tried again. This resulted in the original error: + /opt/openpkg/bin/make --no-print-directory cd tiff && /opt/openpkg/bin/make ../libtool --silent --mode=compile /opt/openpkg/bin/cc -c -I../pdflib -DHAVE_DLFCN_H=1 -DWORDS_BIGENDIAN=1 -O -DPDF_PLATFORM=\""SunOS 5.8"\" tif_auxx.c make[1]: *** [tif_auxx.lo] Error 1 make: *** [libtiff] Error 2 error: Bad exit status from /opt/openpkg/RPM/TMP/rpm-tmp.6688 (%build) RPM build errors: Bad exit status from /opt/openpkg/RPM/TMP/rpm-tmp.6688 (%build) As per your suggestion, I changed to the /opt/openpkg/RPM/TMP/pdflib-4.0.3/tiff directory and ran /opt/openpkg/bin/make with these results: ../libtool --silent --mode=compile /opt/openpkg/bin/cc -c -I../pdflib -DHAVE_DLFCN_H=1 -DWORDS_BIGENDIAN=1 -O -DPDF_PLATFORM=\""SunOS 5.8"\" tif_auxx.c make: *** [tif_auxx.lo] Error 1 For the sake of testing, I backed up a level, removed config.cache, and tried "./configure && make" to see if ./configure without switches would work. Again, the same results. > Because OpenPKG very cleanly controls the build environment (which isn't > the case in (5)), I made another 'alternative' package to troubleshoot. > You can try it, in which it tries to build png before tiff, and with no > make flags: > > # rpm --rebuild > # ftp://ftp.europalab.com/opkgrepo/pdflib-4.0.3-alt2.src.rpm Oops! I started building a new dev machine and missed this test. I will replace the original drives and try this later. > Also it might be raining too much there in Fremont, and so check for leaks > in the roof just above your Sun E250 machine ;-) "Moisture in the junction box" was a favorite joke/excuse with our telecom folks many years ago. However, it hasn't rained in the last few days so our data center should have dried out by now. :) Here is an account of the steps I took to build a new Solaris 8 host. It isn't our normal setup but I wanted to keep the install as simple and clean as possible. It may not be relevent but I'm providing it here in case anyone would like to try to reproduce the environment. I started with "boot cdrom" at the NVRAM prompt. I chose English, the en_US.ISO8859-15 locale, and DEC VT100 for the installation parameters. For installation options, I chose Networked, no DHCP, part of a subnet, no IPv6, no Kerberos, DNS name service, US/Pacific timezone, "Initial" installation, "Standard" (not Flash) interactive install, "U.S.A. (en_US.ISO8859-1)" region support, include 64-bit support, "Core System Support 64-bit", and manual filesystem layout. Then final profile screen looked like this: q Profile qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq The information shown below is your profile for installing Solaris software. It reflects the choices you've made on previous screens. ============================================================================ Installation Option: Initial Boot Device: c0t0d0 Client Services: None Locales: U.S.A. (en_US.ISO8859-1) Software: Solaris 8, Core System Support 64-bit File System and Disk Layout: / c0t0d0s0 501 MB swap c0t0d0s1 259 MB /var c0t0d0s3 5866 MB /home c0t0d0s4 1001 MB /opt c0t0d0s5 1001 MB qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq F2_Continue F4_Change F5_Exit F6_Help This results in the following packages being installed on an E250: # ls /var/sadm/pkg SUNWadmr SUNWcg6x SUNWfcipx SUNWkey SUNWmdi SUNWses SUNWudfr SUNWatfsr SUNWcsd SUNWfcp SUNWkvm SUNWmdix SUNWsesx SUNWudfrx SUNWatfsu SUNWcsl SUNWfcpx SUNWkvmx SUNWnamos SUNWsndmr SUNWusb SUNWauda SUNWcslx SUNWfctl SUNWlibms SUNWnamow SUNWsndmu SUNWusbx SUNWaudd SUNWcsr SUNWfctlx SUNWlmsx SUNWnisr SUNWsolnm SUNWwsr2 SUNWauddx SUNWcsu SUNWftpr SUNWloc SUNWnisu SUNWssad SUNWxwdv SUNWbzip SUNWcsxu SUNWftpu SUNWlocx SUNWpd SUNWssadx SUNWxwdvx SUNWcar SUNWdfb SUNWged SUNWluxdx SUNWpdx SUNWswmt SUNWxwmod SUNWcarx SUNWdtcor SUNWhmd SUNWluxop SUNWpl5u SUNWtleux SUNWxwmox SUNWced SUNWeridx SUNWhmdx SUNWluxox SUNWqfed SUNWuaud SUNWcedx SUNWesu SUNWi15cs SUNWm64 SUNWqfedx SUNWuaudx SUNWcg6 SUNWfcip SUNWi1cs SUNWm64x SUNWrmodu SUNWudf After the install, I added /etc/defaultrouter and fixed /etc/resolv.conf (which is always empty for some reason) so that I could get to ftp.openpkg.org. Then I remembered I had burned the binary 1.1 ISO to CD-ROM so I used that instead. I was going to apply the Solaris recommended and security patches but, untarring the 75MB patch cluster results in a checksum error which, if I recall correctly, is due to the fact that Solaris tar can not handle long pathnames. Since GNU tar is not part of the "core" Solaris installation, I preceded without first patching the system. I copied openpkg-1.1.0-1.1.0.sparc64-solaris2.8-cw.sh to / and installed it from there since trying to run it from the CD-ROM results in: # sh openpkg-1.1.0-1.1.0.sparc64-solaris2.8-cw.sh openpkg-1.1.0-1.1.0.sparc64-solaris2.8-cw.sh: installing into /cw... openpkg-1.1.0-1.1.0.sparc64-solaris2.8-cw.tar.Z: Read-only file system openpkg-1.1.0-1.1.0.sparc64-solaris2.8-cw.sh: openpkg-1.1.0-1.1.0.sparc64-solaris2.8-cw.tar.Z: cannot open tar: blocksize = 0 openpkg-1.1.0-1.1.0.sparc64-solaris2.8-cw.sh: installation done. Then I ran "eval `/cw/etc/rc --eval all env`" and installed gcc, binutils, and make from the binary RPMs on the 1.1 CD=ROM. Assuming this would be enough, I tried "rpm --rebuild ftp://ftp.openpkg.org/release/1.1/SRC/pdflib-4.0.3-1.1.0.src.rpm"; only to be greeted with: checking whether the C compiler (/cw/bin/cc -O ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. error: Bad exit status from /cw/RPM/TMP/rpm-tmp.9730 (%build) RPM build errors: Bad exit status from /cw/RPM/TMP/rpm-tmp.9730 (%build) I didn't really expect to be able to build on such a stripped down system and a quick hello.c confirmed a problem with stdio.h (SUNWhea is not installed as part of a "core" install). On a side note, the stdio.h included in the gcc RPM claims to be derived from /usr/include/stdio.h (which did not exist on my system at the time) and contains Sun copyright notices. Since that appears to be distributed in the binary RPM, I don't know if that should concern anyone or not. Anyway, adding SUNWhea got me past compiling to the loader (linker? anyone feel free to jump in and correct my assumptions/terminology, I don't claim to be a programming guru.). My "hello world" program was now returning: /cw/bin/ld: cannot open values-Xa.o: No such file or directory collect2: ld returned 1 exit status I remembered seeing this error before with gcc on Solaris 8 and did a Google search to find the answer. After adding SUNWarc and SUNWarcx, my "hello world" program compiled an ran fine. I tried the "rpm --rebuild ..." command and got this: ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found make[1]: *** [tif_auxx.lo] Error 1 make: *** [libtiff] Error 2 error: Bad exit status from /cw/RPM/TMP/rpm-tmp.1851 (%build) RPM build errors: Bad exit status from /cw/RPM/TMP/rpm-tmp.1851 (%build) I was running the build as the cw user created by the binary bootstrap sh script. The shell for that user is /cw/lib/openpkg/bash. As root, I changed the cw user's shell to /bin/ksh, ran "su - cw" and then "eval `/cw/etc/rc --eval all env`" and tried again. However, I could see that it was still using using /cw/lib/openpkg/bash. After a lot of experimentation including changing the shells for all the cw* users and root, I found that it was getting the shell from /cw/etc/openpkg/rpmmacros. Making a change to this file (a bad idea, I know) also did not work. I put the shells and rpmmacros back to their original state and created /bin/print as a shell script that echoed the second parameter (an ugly workaround, I know). Then I got: cd tiff && /cw/bin/make ../libtool --silent --mode=compile /cw/bin/cc -c -I../pdflib -DHAVE_DLFCN_H=1 -DWORDS_BIGENDIAN=1 -O -DPDF_PLATFORM=\""SunOS 5.8"\" tif_auxx.c In file included from port.h:14, from tiffiop.h:33, from tif_auxx.c:33: /cw/lib/gcc-lib/sparc-sun-solaris2.8/3.2/include/math.h:25:26: iso/math_iso.h: No such file or directory make[1]: *** [tif_auxx.lo] Error 1 make: *** [libtiff] Error 2 error: Bad exit status from /cw/RPM/TMP/rpm-tmp.22733 (%build) RPM build errors: Bad exit status from /cw/RPM/TMP/rpm-tmp.22733 (%build) Back to Solaris media to install SUNWlibm and SUNWlmx. Both wanted SUNWtoo as a prerequisite but, SUNWtoo is on the first CD-ROM and I only needed the libraries so I installed them without SUNWtoo and tried again. This time, I got farther than any of my previous attempts: ../libtool --silent --mode=link /cw/bin/cc -o libpdf_.la ./p_afm.lo ./p_annots.lo ./p_basic.lo ./p_ccitt.lo ./p_color.lo ./p_draw.lo ./p_filter.lo ./p_font.lo ./p_gif.lo ./p_gstate.lo ./p_hyper.lo ./p_image.lo ./p_jpeg.lo ./p_md5.lo ./p_params.lo ./p_pattern.lo ./p_pfm.lo ./p_png.lo ./p_stream.lo ./p_text.lo ./p_truetype.lo ./p_tiff.lo ./p_template.lo ./p_unicode.lo ./p_util.lo -export-dynamic -lm ../libtool --silent --mode=link /cw/bin/cc -o libpdf.la ../pdflib/libpdf_.la ../png/libpng.la ../tiff/libtiff.la ../flate/libz.la -lm -export-dynamic -lm libtool: link: `../pdflib/libpdf_.la' is not a valid libtool archive make[1]: *** [libpdf.la] Error 1 make: *** [pdflib] Error 2 error: Bad exit status from /cw/RPM/TMP/rpm-tmp.1739 (%build) RPM build errors: Bad exit status from /cw/RPM/TMP/rpm-tmp.1739 (%build) OK, so maybe it really does need SUNWtoo. Added SUNWtoo and SUNWtoox but results were the same. At this point, I'm beyond "--mode=compile" which was failing on the original system. I put the original system back and made sure it had the same Solaris packages and found "suspicious" things (like the SUNWhea for i386 package was installed when it is a sun4u box). I suspect my setup is too blame. I'm done for today but I may scrap this config and start over. ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List [EMAIL PROTECTED]
