Use of /usr/ccs/bin on Solaris

[Martin Buchholz]

If the user has not explicitly provided an nm (i.e. almost always) then it
makes sense for the configure script to test the nm that may be on the
PATH, and if that's definitely not good enough (are you sure? gnu nm also
supports linker scripts), fall back to /usr/ccs/bin/nm.

On Mon, Mar 9, 2015 at 11:20 AM, Dmitry Samersoff <
dmitry.samersoff at oracle.com> wrote:

> 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.
>