dev-libs/libpcre installs '${EPREFIX}/usr/lib/libpcre.so -> ../../lib/libpcre.so', yet ${EPREFIX}/lib/ contains only: libpcre.so.1 -> libpcre.so.1.1 libpcre.so.1.1 Creating a 'libpcre.so -> libpcre.so.1.1' symlink fixes this, and allows grep to build.
Ah, this is because on IRIX I can't read the soname of the dynamic object. Does pax-utils by chance compile/install on IRIX? (And does it also work with object files on IRIX?)
I think I fixed this (as in, retaining the symlink you had missing), but still, if I can read the soname of the object, we can create a symlink to the right object which is nicer.
pax-utils fails with: >>> Compiling source in /usr/opt/gentoo/var/tmp/portage/app-misc/pax-utils-0.1.18/work/pax-utils-0.1.18 ... make CC=cc LIBS= USE_CAP= cc -c99 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip30:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035 -woff 1174,1183,1185,1552,3968,3970 -I/opt/gentoo/usr/include -D_GNU_SOURCE -DVERSION="0.1.18" -o paxelf.o -c paxelf.c cc-1035 cc: ERROR File = porting.h, Line = 147 #error directive: "no idea what the native byte order is" # error "no idea what the native byte order is" ^ cc-1018 cc: ERROR File = paxinc.h, Line = 103 An unmatched left parentheses "(" appears in an expression. #define warn(fmt, args...) \ ^ cc-1018 cc: ERROR File = paxinc.h, Line = 105 An unmatched left parentheses "(" appears in an expression. #define warnf(fmt, args...) warn("%s%s%s(): " fmt, YELLOW, __FUNCTION__, NORM , ## args) ^ cc-1018 cc: ERROR File = paxinc.h, Line = 106 An unmatched left parentheses "(" appears in an expression. #define warnp(fmt, args...) warn(fmt ": %s" , ## args , strerror(errno)) ^ cc-1018 cc: ERROR File = paxinc.h, Line = 107 An unmatched left parentheses "(" appears in an expression. #define warnfp(fmt, args...) warnf(fmt ": %s" , ## args , strerror(errno)) ^ cc-1018 cc: ERROR File = paxinc.h, Line = 108 An unmatched left parentheses "(" appears in an expression. #define _err(wfunc, fmt, args...) \ ^ cc-1018 cc: ERROR File = paxinc.h, Line = 113 An unmatched left parentheses "(" appears in an expression. #define err(fmt, args...) _err(warn, fmt, ## args) ^ cc-1018 cc: ERROR File = paxinc.h, Line = 114 An unmatched left parentheses "(" appears in an expression. #define errf(fmt, args...) _err(warnf, fmt, ## args) ^ cc-1018 cc: ERROR File = paxinc.h, Line = 115 An unmatched left parentheses "(" appears in an expression. #define errp(fmt, args...) _err(warnp, fmt , ## args) ^ ... I'll take a look at whether the package is fixable next week, but for now it's probably safe to assume that pax-utils isn't currently available.
it's full of gnu-isms, so that's a no. Is there a host tool on IRIX that can read sonames?
I'm not sure, TBH... what might such a tool be called, or what associated utilities might be included with it?
'objdump' includes SONAME in its output when invoked with '-x'... but it looks as this might have been a left-over from an attempt to install binutils from Portage.
Have you had a chance to test if this is properly fixed in the eclass now?
I've just this minute rebuilt libpcre, and the broken symlink is back :(
Did you notice any warnings or error messages? I think I found a bug in the eclass code, it should look like this: if ${auto} ; then mv "${ED}"/usr/${libdir}/${lib}* "${ED}"/${libdir}/ || die # no way to retrieve soname on these platforms (?) tlib=$(readlink "${ED}"/${libdir}/${lib}) tlib=${tlib##*/} if [[ -z ${tlib} ]] ; then # ok, apparently was not a symlink, don't remove it and # just link to it tlib=${lib} else rm -f "${ED}"/${libdir}/${lib} fi else tlib=${lib} fi (note the last else/if with tlib=${lib}) Could you try and see if this does the right thing?
Looks as if, although I'd sync'd, I'd not got that update. I've sync'd again and rebuild libpcre, and not the symlink is created. Problem solved, so far as I can see :)
(In reply to comment #10) > > I've sync'd again and rebuild libpcre, and not the symlink is created. Problem > solved, so far as I can see :) > Good grief, let's try that again in English: I've sync'd again and rebuilt libpcre, and now the symlink is created correctly. So far as I can see, problem solved :)
good, thanks!
