On 03/12/12 10:10 AM, Edwin Beasant wrote:
Hi there :

>The problem appears to be that the ksh93 AT&T build system builds everything into the directories as seen here (/prototype/sparc/sparcv9/bin/....), which of course has a 64 bit runpath to the $(ORIGIN)../lib if the tree was installed in the way that the AT&T build system likes to build it....
I am relocating the binaries at packaging time to /usr/bin/$(MACH64), and performing the isaexec dance on them too.

(As a side note It would be far simpler to only build these as 64-bit deliverables, it would save significant complexity and these warnings too :-)
While the runpath entries that caused these warning to appear aren't necessarily harmful, It would be better to link these executables without '$ORIGIN/../lib'. Since ksh is always going to install in the same location and we really want our version to search for shared libraries in the locations that we control, dropping $ORIGIN/../lib from the runpath seems like a safe option.

Thanks - that's useful to know :-) do you have a recommended way of doing this ?
I haven't looked at the AT&T build, so I don't know how complicated it is, but ideally you would patch it so that it doesn't link with '-R$ORIGIN/../lib' presumably it's embedded in one of their Makefiles.



And this one, which I think is actually unavoidable, as this matches the existing packaging (which is necessary)

WARNING pkglint.manifest004 last name component ksh in package name clashes across pkg://solaris/source/demo/[email protected],5.11-0.175.1.0.0.11.0:20120305T212615Z pkg:/shell/ksh@20110208,5.11-0.175.1.0.0.11.757
Yes, this one is unavoidable. You can turn it 'off' by adding 'pkg.linted.pkglint.manifest004=true' to your manifest, though we don't do that for the other 'clashes'.

If its OK to leave it, I'd prefer that it was seen rather than 'hidden' if that makes any sense?
The other instances where this occurs in the gate just spew the warning, so yes, it's ok. Actually, adding the pkg.linted bit doesn't make it silent.

    -Norm

Cheers,
Edwin

_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss

_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss

Reply via email to