Bruce Momjian wrote:
> Tom Lane wrote:
>
>> Alan Stange <stange@rentec.com> writes:
>>
>>> Tom Lane wrote:
>>>
>>>> Nobody else has complained of this, so the least you could do is
>>>> identify which Solaris version and exactly which compiler you're
>>>> talking about.
>>>>
>>> I just tried building on all of these combinations:
>>>
>>> Solaris 10: compilers 6.2 and 11
>>> Solaris 9: compilers 8, 9, 10, 11
>>> Solaris 8: compilers 6.2, 9, 11
>>>
>>> Postgresql 8.1.3 fails to compile on all of them with --enable-debug
>>>
>> OK, that's a reasonably convincing sample ;-). Will fix. Thanks
>> for the report!
>>
>
> Uh, backend/port/tas/solaris*.s ASM files have "section" like:
>
> .section ".text"
>
> Are these OK? I didn't see you report any problems with these.
>
Without looking at the code (I'm home now) the main difference is that
the .s file will somewhere need a .text section. The issue in a .c file
is that one is already in the context of a .text section given that one
is in the tas_dummy() {} basic block. The .data and .text sections in
the embedded asm code is then just confusing the assembler. When the
optimizer is turned on, the .sections are possibly relocated, which
allows the fbe backend to successfully compute the .size value.
I'll remove the _tas: assembler code from the s_lock.c file and test if
the code compiles/runs on one or two solaris+compiler combinations.
I'll certainly compile on all again just to be sure.
-- Alan