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.bur...@oracle.com <mailto:magnus.ihse.bur...@oracle.com>> > wrote: > > > > 6 mar 2015 kl. 20:17 skrev Dmitry Samersoff > <dmitry.samers...@oracle.com <mailto:dmitry.samers...@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.
