Use of /usr/ccs/bin on Solaris

[Dmitry Samersoff]

Martin,

if we *append* /usr/ccs/bin to the path we are in risk that configure
picks GNU tool instead of solaris one.

if we *prepend* /usr/ccs/bin to the path we lost an ability to override
/usr/ccs/bin tool with user-supplied one.

So both solutions above looks bad for me.

And yes, this all is mostly about *nm*

-Dmitry


On 2015-03-09 20:03, Martin Buchholz wrote:
> I support Magnus' strategy.
> 
> Slightly unrelated, /usr/ccs/bin is a very old directory, and ISTR that
> it was slowly going away.
> 
> On SunOS 5.10 I see a cornucopia of nm's muddying the waters:
> /usr/ccs/bin/sparcv9/nm
> /usr/ccs/bin/nm
> /usr/xpg4/bin/nm
> /usr/sfw/sparc-sun-solaris2.10/bin/nm
> 
> 
> On Fri, Mar 6, 2015 at 10:09 PM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>>
> wrote:
> 
> 
>     > 6 mar 2015 kl. 20:17 skrev Dmitry Samersoff
>     <dmitry.samersoff at oracle.com <mailto:dmitry.samersoff at oracle.com>>:
>     >
>     > Magnus,
>     >
>     > You can add a generic warning:
>     >
>     > if configure fails finding some tools and it's solaris
>     > then
>     >  warn about /usr/ccs/bin that should be in a path
>     > end
> 
>     This is exactly what I said would be technically hard to do. Much
>     harder than what's justified for this issue.
> 
>     >
>     > I'm against of altering PATH any way (appending or prepending anything)
>     > because it might lead to the situation where wrong tool is picked and
>     > it's hard to debug.
> 
>     I think we might just be misunderstanding each other here. Configure
>     will not (and in fact cannot) alter the user's PATH in his/her
>     environment.
> 
>     We do use the PATH as one way - but not the only way - to find tools
>     needed to be able to build. One of the design goals of the configure
>     script is "if the tool exist on the system, we should find it". This
>     is to minimize the amount of configuration needed by the user.
> 
>     If you are worried that configure should find a tool that would
>     work, but not be the exact version that you wanted, then you will
>     have to point it out for configure, using eg. --with-devkit,
>     --with-bootjdk, SED=, GREP= etc.
> 
>     So looking in /usr/ccs/bin instead of failing, is just like the rest
>     of the processing configure does.
> 
>     /Magnus
> 
>     >
>     > -Dmitry
>     >
>     >
>     >
>     >> On 2015-03-06 17:50, Magnus Ihse Bursie wrote:
>     >>> On 2015-03-04 22:03, Martin Buchholz wrote:
>     >>> I agree that configure should not mess with user's PATH and should
>     >>> "auto-find" programs in /usr/ccs/bin only as a last resort.
>     >>>
>     >>> It would be reasonable, when configure fails on Solaris, to notice
>     >>> that the
>     >>> user does not have /usr/ccs/bin on PATH and suggest appending.
>     >>
>     >> I have opened https://bugs.openjdk.java.net/browse/JDK-8074557.
>     >>
>     >> Adding a warning to failed configure on Solaris due to missing build
>     >> tools that presumably resides in /usr/ccs/bin seems like quite a
>     lot of
>     >> work.
>     >>
>     >> I suggest the following:
>     >> Instead of prepending, append /usr/ccs/bin, so any binaries in the
>     >> user's specified PATH are picked first. This will allow a
>     properly set
>     >> PATH to function, but it will still provide the "best effort"
>     approach
>     >> of configure to look in "well-known locations" for tools.
>     >>
>     >> Does that seem like an acceptable solution?
>     >>
>     >> /Magnus
>     >
>     >
>     > --
>     > Dmitry Samersoff
>     > Oracle Java development team, Saint Petersburg, Russia
>     > * I would love to change the world, but they won't give me the
>     sources.
> 
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.