Solaris compiler setup ?

[Erik Joelsson]

I have looked at this problem and this is what happens:

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.

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

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.

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.

/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