Hi there:
On 29/10/12 17:52, Craig Mohrman wrote:
Hello,
I'm trying to build perl 64-bit, in userland, for the first time and I'm
running into this during packaging:
/usr/bin/pkglint -c
/builds3/cmohrman/userland_perl516_s12-V2/i386/pkglint-cache \
-f /builds3/cmohrman/userland_perl516_s12-V2/tools/pkglintrc
/builds3/cmohrman/userland_perl516_s12-V2/components/perl516/build/manifest-i386-perl-516-64.depend.res
/builds3/cmohrman/userland_perl516_s12-V2/components/perl516/build/manifest-i386-perl-516.depend.res
Lint engine setup...
Starting lint run...
WARNING userland.action001.3 32-bit runpath in 64-bit binary,
'/builds3/cmohrman/userland_perl516_s12-V2/components/perl516/build/prototype/i386/usr/perl5/5.16-64/bin/perl5.16.1'
includes '/usr/perl5/5.16-64/lib/i86pc-solaris-64/CORE'
For this error:
You've probably got RPATH=$(ORIGIN)../lib creeping into that object, or
some version of /usr/lib being introduced into the runpath - IIRC this
is why all objects compiled using full userland CFLAGS get "-norunpath"
as an option. You'll need to sift through the created objects with
elfdump to find it:
To check an objects runpath manually:
----
# elfedit <object/binary>
> dyn:rpath
----
As I understand it:
First thing to do is to try to fix the build system so that a runpath is
not introduced at all.
Its a side effect of linking against libraries in a tree that is not the
same shape as the target filesystem: if an RPATH is introduced, it will
be calculated *in the build tree*, and $ORIGIN will almost always be
wrong for 64-bit objects linked like this: Using the pkg system to
relocate the binaries to the right place (from their location in the
build tree) exposes this problem - if the build/install tree is forced
to be the same shape as the solaris platform its intended for, it avoids
this issue as any calculated runpath will be correct. This may be
necessary if it is impossible to trace/prevent the introduction of a
runpath into the object.
ERROR userland.action001.2 64-bit object
'usr/perl5/5.16-64/lib/i86pc-solaris-64/CORE/libperl.so' in 32-bit path
ERROR userland.action001.2 64-bit object
'usr/perl5/5.16-64/lib/i86pc-solaris-64/auto/B/B.so' in 32-bit path
Hmm - not sure about this one:
I had similar issues with ksh93 and had to deliver libraries to
/usr/lib/$(MARCH)/ (and symlink accross) to resolve it: ksh93 doesn't
deliver any libraries any more though :-)
That would require digging into the pkglint in userland a bit more...
I'm not an expert...
Cheers,
Edwin
I have verified that all objects are 64-bit:
$ file usr/perl5/5.16-64/lib/i86pc-solaris-64/CORE/libperl.so
usr/perl5/5.16-64/lib/i86pc-solaris-64/CORE/libperl.so: ELF 64-bit LSB dynamic
lib AMD64 Version 1 [SSE2 SSE CMOV FPU], dynamically linked, not stripped
$ file
/builds3/cmohrman/userland_perl516_s12-V2/components/perl516/build/prototype/i386/usr/perl5/5.16-64/bin/perl5.16.1
/builds3/cmohrman/userland_perl516_s12-V2/components/perl516/build/prototype/i386/usr/perl5/5.16-64/bin/perl5.16.1:
ELF 64-bit LSB executable AMD64 Version 1 [SSE FXSR FPU], dynamically
linked, not stripped
I'm guessing the problem is the string 'i86pc-solaris-64' which perl
creates from the commands arch or mach.
Is "i86pc" making pkglint believe this is a 32-bit object?
I've tried configuring perl to use amd64 instead of i86pc but perl Configure
keeps overriding me. I'll have to patch perl's Configure to really fix it.
Or should I just override the pkglint errors/warnings with
pkg.linted.pkglint.???
directives?
Many thanks,
craig
_______________________________________________
userland-discuss mailing list
userland-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
_______________________________________________
userland-discuss mailing list
userland-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
