Solaris compiler setup ?

[David Holmes]

On 6/12/2012 1:19 AM, Erik Joelsson wrote:
> I have looked at this problem and this is what happens:

Thanks for persevering Erik!

> In toolchain.m4, AC_CHECK_TOOL is finding ar in the path. We then call
> BASIC_FIXUP_EXECUTABLE (in basics.m4) to resolve ar to an absolute path
> basically using the command which. However, on this machine, which
> outputs nothing on stdout when run inside configure.

Okay but we see a problem with which for other tools, yet it somehow 
found their full paths eg:

configure: Resolving CXX (as /java/devtools/i386/SUNWspro/SS12u1/bin/CC) 
with 'which' failed, using /java/devtools/i386/SUNWspro/SS12u1/bin/CC 
directly.

Why don't I see:

configure: Resolving AR (as /usr/ccs/bin/ar) with 'which' failed, using 
/usr/ccs/bin/ar directly.

? Is it a difference in how AC_CHECK_TOOL works versus AC_PATH_PROG? Can 
we not use the latter instead?

> Digging futher, I checked stderr, where it says:
> `tty`: Ambiguous

Yes I see that a bit.

> A bit of googling suggests that this is caused by something bad in
> .login or similar file. Something around "tty" outputting "not a tty"
> which it does when run inside configure. /usr/bin/which on Solaris is a
> csh script.

Yes and csh is a real problem on Solaris 10 because of the complex CDE 
(Common User Environment) setup that is involved. :(

> I don't know how to solve this. I can just conclude that on the solaris
> machine I'm developing on, this isn't happening.

Are you on Solaris 11? Send me a copy of your /usr/bin/which script.

Thanks,
David

> /Erik
>
> On 2012-12-03 05:45, David Holmes wrote:
>> Continuing the sad tale ....
>>
>> checking for cc... /java/devtools/i386/SUNWspro/SS12u1/bin/cc
>> configure: Resolving CC (as
>> /java/devtools/i386/SUNWspro/SS12u1/bin/cc) with 'which' failed, using
>> /java/devtools/i386/SUNWspro/SS12u1/bin/cc directly.
>> checking resolved symbolic links for CC...
>> /java/devtools/i386/SUNWspro/SS12u1/prod/bin/cc
>> checking if CC is disguised ccache... no, keeping CC
>> configure: Using Sun Studio C compiler version 5.10 (located at
>> /java/devtools/i386/SUNWspro/SS12u1/prod/bin/cc)
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables...
>> checking whether we are cross compiling... no
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... no
>> checking whether /java/devtools/i386/SUNWspro/SS12u1/prod/bin/cc
>> accepts -g... yes
>> checking for /java/devtools/i386/SUNWspro/SS12u1/prod/bin/cc option to
>> accept ISO C89... none needed
>> checking for cl... no
>> checking for CC... /java/devtools/i386/SUNWspro/SS12u1/bin/CC
>> configure: Resolving CXX (as
>> /java/devtools/i386/SUNWspro/SS12u1/bin/CC) with 'which' failed, using
>> /java/devtools/i386/SUNWspro/SS12u1/bin/CC directly.
>> checking resolved symbolic links for CXX...
>> /java/devtools/i386/SUNWspro/SS12u1/prod/bin/CC
>> checking if CXX is disguised ccache... no, keeping CXX
>> configure: Using Sun Studio C++ compiler version 5.10 (located at
>> /java/devtools/i386/SUNWspro/SS12u1/prod/bin/CC)
>> checking whether we are using the GNU C++ compiler... no
>> checking whether /java/devtools/i386/SUNWspro/SS12u1/prod/bin/CC
>> accepts -g... yes
>> checking for ar... ar
>> configure: The path of AR, which resolves as "ar", is not found.
>> configure: error: Cannot locate the the path of AR
>> configure exiting with result code 1
>>
>>
>> But:
>>
>> > which ar
>> /usr/ccs/bin/ar
>>
>> David
>> ------
>>
>> On 1/11/2012 6:49 PM, Erik Joelsson wrote:
>>> Yes, I've noticed this too since this is how I always configure, but was
>>> already busy with too many parallel threads of development to fix it
>>> right away. Workaround is to touch spec.gmk and then run configure. I
>>> will go fix it now.
>>>
>>> /Erik
>>>
>>> On 2012-11-01 05:23, David Holmes wrote:
>>>> On 30/10/2012 5:39 AM, Magnus Ihse Bursie wrote:
>>>>> On 2012-10-26 16:36, Magnus Ihse Bursie wrote:
>>>>>>> Pretty sure I don't need objective-C on Solaris :-)
>>>>>> I have a fix for that already. :-) But I'll want to double check that
>>>>>> on our test systems before I push it, so I don't put the current
>>>>>> integration in jeopardy.
>>>>>
>>>>> I forgot to push that fix. Done now.
>>>>>
>>>>> How far do you get this time? :-)
>>>>
>>>> Not too far :(
>>>>
>>>> checking for mozilla headers in /java... /java/devtools/share/plugin
>>>> checking for devtools path in /java... /java/devtools/i386/bin
>>>> checking for GCC compiler path in /java...
>>>> /java/devtools/i386/gnucc/bin
>>>> configure: Current directory is
>>>> /java/embedded/users/dh198349/build-infra/builds/b01/se-solaris-i586-ea.
>>>>
>>>> configure: Since this is not the source root, configure will output
>>>> the configuration here
>>>> configure: (as opposed to creating a configuration in
>>>> <src_root>/build/<conf-name>).
>>>> configure: However, this directory is not empty. This is not allowed,
>>>> since it could
>>>> configure: seriously mess up just about everything.
>>>> configure: Try 'cd /java/embedded/users/dh198349/build-infra' and
>>>> restart configure
>>>> configure: (or create a new empty directory and cd to it).
>>>> configure: error: Will not continue creating configuration in
>>>> /java/embedded/users/dh198349/build-infra/builds/b01/se-solaris-i586-ea
>>>> configure exiting with result code 1
>>>>
>>>> ---
>>>>
>>>> > ls -l b01/se-solaris-i586-ea
>>>> total 40
>>>> -rw-r--r-- 1 daholme staff 19688 Nov 1 00:18 config.log
>>>>
>>>>
>>>> Is it tripping over its own output file ??? My script creates the
>>>> output directory then cd's to it and invokes configure.
>>>>
>>>> David
>>>> -----
>>>>
>>>>>
>>>>> /Magnus