Re: solaris build problem with Sun compilers
От | Alan Stange |
---|---|
Тема | Re: solaris build problem with Sun compilers |
Дата | |
Msg-id | 4463D639.3030802@rentec.com обсуждение исходный текст |
Ответ на | Re: solaris build problem with Sun compilers (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: solaris build problem with Sun compilers
|
Список | pgsql-ports |
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
В списке pgsql-ports по дате отправления: