On 12/06/11 19:13, Rich Burridge wrote:
On 12/05/2011 10:29 AM, Norm Jacobs wrote:
It seems as though you would want to remove /usr/ccs/lib and /usr/ccs/lib/libp
from both the search path and run path if you are removing them.
Indeed. And after more discussion off-list (thanks to every one
involved), this bug will now cover the following adjustments:
* remove all/usr/ccs/... references in the search and runtime paths
in the sol2.h.patch file.
* remove all /lib and /usr/lib (32 bit) and /lib/64 and /usr/lib/64 (64 bit)
references from the runpath strings in the three patch files (sol2.h.patch,
i386.sol2-10.h.patch and sparc.sol2-bi.h.patch). These two directories are
the default runpaths and will be searched last by default.
* move all/usr/sfw/... references to the front of the search and the
run paths in all three patch files. A recent bug (7094108) exposed
this problem.
New webrev is at:
http://jurassic.us.oracle.com/~richb/7080051-v2/
x86 workspace is at:
/net/stard.us.oracle.com/tank/ws/UL/7080051/
See the bug report for the results of a simple gcc3 compile
(32 and 64 bit) and the elfdump -d results it generated. I
also built and ran GNU core-utils with this new compiler.
Thanks.
I'll take your word for the fact that those cryptic headers have
the effect you described... :-)
The use of 'elfdump -d' to examine the resulting object is
a good idea. Have you verified the link-editor search path?
% LD_OPTIONS=-Dargs gcc hello.c
And it might be good insurance to do an ON build with __GNUC to
ensure that those continue to work. I wouldn't expect this to break
them, but as I learned again last week, it's best not to guess.
Looks good to me...
- Ali
_______________________________________________
userland-discuss mailing list
userland-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
