Bug 83802
Summary: | RPM 4.2-066 fails to compile on Solaris 8 | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Donnie Cranford <mozilla> |
Component: | rpm | Assignee: | Jeff Johnson <jbj> |
Status: | CLOSED WORKSFORME | QA Contact: | Mike McLean <mikem> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | herrold |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | sparc | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-03-08 17:44:54 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Donnie Cranford
2003-02-09 01:59:35 UTC
CCing herold Update ----------------------------------------------------------- Using the Forte 7 compiler, I get an entirely different error, (well it doesnt get as far as GCC) here is what I get in forte, same .profile /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I. -I. -DMAGIC='"/usr/local/lib/rpm/magic"' -I/usr/local/include -I/usr/local/BerkeleyDB/include -I/opt/sfw/include -I/opt/sfw/include/db1 -I/opt/sfw/include/db3 -I/usr/include -I/usr/openwin/include -c `test -f 'file.c' || echo './'`file.c "system.h", line 253: warning: implicit function declaration: error "file.h", line 98: syntax error before or at: ( "file.h", line 98: warning: syntax error: empty declaration "file.c", line 221: syntax error before or at: : cc: acomp failed for file.c ok, was able ot get around -lz linking issue by adding a static libz, however now compile is failing with an unresolved symbol /bin/bash ./libtool --mode=link /usr/local/bin/gcc -I/usr/local/include -I/usr/local/BerkeleyDB/include -I/opt/sfw/include -I/opt/sfw/include/db1 -I/opt/sfw/include/db3 -I/usr/include -I/usr/openwin/include -o test1 -all-static test1.o libpopt.la -L/usr/ucblib -R /usr/ucblib /usr/local/bin/gcc -I/usr/local/include -I/usr/local/BerkeleyDB/include -I/opt/sfw/include -I/opt/sfw/include/db1 -I/opt/sfw/include/db3 -I/usr/include -I/usr/openwin/include -o test1 -static test1.o ./.libs/libpopt.a -L/usr/ucblib -R/usr/ucblib Undefined first referenced symbol in file libintl_dgettext ./.libs/libpopt.a(popt.o) ld: fatal: Symbol referencing errors. No output written to test1 collect2: ld returned 1 exit status this is using xgettext 0.11.5 HOWEVER when doing a ./configure --with-included-gettext I get the following error /bin/bash ../libtool --mode=link /usr/local/bin/gcc -I/usr/local/include -I/usr/local/BerkeleyDB/include -I/opt/sfw/include -I/opt/sfw/include/db1 -I/opt/sfw/include/db3 -I/usr/include -I/usr/openwin/include -D_GNU_SOURCE -D_REENTRANT -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -o librpmio.la -rpath /usr/local/lib -release 4.2 ../file/libfmagic.la ../zlib/libz.la -lrt -lpthread argv.lo digest.lo fts.lo macro.lo rpmio.lo rpmlog.lo rpmmalloc.lo rpmpgp.lo rpmrpc.lo strcasecmp.lo stubs.lo url.lo ugid.lo aes.lo aesopt.lo base64.lo beecrypt.lo blockmode.lo blockpad.lo blowfish.lo blowfishopt.lo dhaes.lo dldp.lo dlkp.lo dlpk.lo dlsvdp-dh.lo dsa.lo elgamal.lo endianness.lo entropy.lo fips186.lo hmac.lo hmacmd5.lo hmacsha1.lo hmacsha256.lo md5.lo memchunk.lo mp32.lo mp32barrett.lo mp32number.lo mp32opt.lo mp32prime.lo mtprng.lo rsa.lo rsakp.lo rsapk.lo sha1.lo sha1opt.lo sha256.lo timestamp.lo -lrt -lpthread -lsocket -lnsl -L../zlib -R../zlib -L/usr/local/lib -R/usr/local/lib -L/usr/ucblib -R/usr/ucblib -lbz2 libtool: link: only absolute run-paths are allowed make[2]: *** [librpmio.la] Error 1 I think im getting closer but not there yet.... any ideas Ok, here is a issue, there are 2 places where rpm-4.2.0-66 dies because of only absolute run paths allowd, rpm/rpmio/Makefile Where you have -L${top_builddir}/zlib and -R${top_builddir}/zlib and rpm/tools/Makefile -L${top_builddir}/zlib and -R${top_builddir}/zlib They both have to have the absolute pathname to compile Here is the current issue I must do --without-python(which is fine for now). The biggest error that I am seeing now actually has to do with elf and what looks like problematic headers here is the output (warning is is quite a bit) /usr/local/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I.. -I../build -I../lib -I../rpmdb -I../rpmio -I../popt -I../file -I../zlib -I../misc -I/usr/local/include -I/usr/local/BerkeleyDB/include -I/usr/local/BerkeleyDB.3.3 -I/usr/include -I/usr/openwin/include -D_GNU_SOURCE -D_REENTRANT -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -c `test -f 'debugedit.c' || echo './'`debugedit.c debugedit.c:23:22: byteswap.h: No such file or directory debugedit.c:24:20: endian.h: No such file or directory In file included from /usr/include/gelf.h:11, from debugedit.c:36: /usr/include/libelf.h:28:2: #error "large files are not supported by libelf" debugedit.c:37:19: dwarf.h: No such file or directory debugedit.c: In function `read_abbrev': debugedit.c:289: `DW_FORM_indirect' undeclared (first use in this function) debugedit.c:289: (Each undeclared identifier is reported only once debugedit.c:289: for each function it appears in.) debugedit.c: In function `edit_dwarf2_line': debugedit.c:479: warning: implicit declaration of function `alloca' debugedit.c: In function `edit_attributes': debugedit.c:676: `DW_AT_stmt_list' undeclared (first use in this function) debugedit.c:678: `DW_FORM_data4' undeclared (first use in this function) debugedit.c:685: `DW_AT_comp_dir' undeclared (first use in this function) debugedit.c:686: `DW_FORM_strp' undeclared (first use in this function) debugedit.c:711: `DW_TAG_compile_unit' undeclared (first use in this function) debugedit.c:713: `DW_AT_name' undeclared (first use in this function) debugedit.c:751: `DW_FORM_addr' undeclared (first use in this function) debugedit.c:754: `DW_FORM_ref1' undeclared (first use in this function) debugedit.c:755: `DW_FORM_flag' undeclared (first use in this function) debugedit.c:756: `DW_FORM_data1' undeclared (first use in this function) debugedit.c:759: `DW_FORM_ref2' undeclared (first use in this function) debugedit.c:760: `DW_FORM_data2' undeclared (first use in this function) debugedit.c:763: `DW_FORM_ref4' undeclared (first use in this function) debugedit.c:767: `DW_FORM_ref8' undeclared (first use in this function) debugedit.c:768: `DW_FORM_data8' undeclared (first use in this function) debugedit.c:771: `DW_FORM_sdata' undeclared (first use in this function) debugedit.c:772: `DW_FORM_ref_udata' undeclared (first use in this function) debugedit.c:773: `DW_FORM_udata' undeclared (first use in this function) debugedit.c:776: `DW_FORM_ref_addr' undeclared (first use in this function) debugedit.c:780: `DW_FORM_string' undeclared (first use in this function) debugedit.c:783: `DW_FORM_indirect' undeclared (first use in this function) debugedit.c:786: `DW_FORM_block1' undeclared (first use in this function) debugedit.c:789: `DW_FORM_block2' undeclared (first use in this function) debugedit.c:793: `DW_FORM_block4' undeclared (first use in this function) debugedit.c:797: `DW_FORM_block' undeclared (first use in this function) debugedit.c: In function `fdopen_dso': debugedit.c:1017: `ELF_C_RDWR_MMAP' undeclared (first use in this function) make[2]: *** [debugedit.o] Error 1 make[2]: Leaving directory `/tmp/rpm-4.2/tools' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/rpm-4.2' make: *** [all] Error 2 any ideas here would be great, I think im pretty close to having this ported then I can work backwards and get it retested and submit diffs ;) You need debugedit iff you want/need to produce sub-packages with debugging symbols. Disable for now, use the latest elfutils package if/when you choose to try to pursue. Jeff how do I disable debugedit?? just comment it out?? I dont know of any configure option Edit the makefile. rpm-4.2-0.70 should revert to internal copy of elfutils-0.76 which should be useful even on solaris. There's almost certainly more to do on solaris, as elfutils is still under development. Please open a new bug report if there are other solaris compilation problems. |