orafce does NOT build with Sun Studio compiler

Started by Mayuresh Nirhalialmost 18 years ago7 messageshackers
Jump to latest
#1Mayuresh Nirhali
Mayuresh.Nirhali@Sun.COM

Hello hackers,

During the Oracle migration tutorial by peter at PGCon, I took an action
item for myself to try orafce on Solaris/OpenSolaris.
As pg binaries are bundled with Solaris now (using Sun Studio compiler),
I decided to try out building orafce against the same bundled binaries
(with USE_PGXS=1).

I see following build error,
/opt/SUNWspro/SS11/bin/cc -xc99=none -xCC -KPIC -I.
-I/usr/include/pgsql/server -I/usr/include/pgsql/internal
-I/usr/sfw/include -I/usr/include/kerberosv5 -c -o pipe.o pipe.c
"pipe.c", line 149: null dimension: data
cc: acomp failed for pipe.c
gmake[1]: *** [pipe.o] Error 2
gmake[1]: Leaving directory `/builds2/postgres/orafce/orafce'
*** Error code 2
make: Fatal error: Command failed for target `orafce/config.status'
Current working directory /builds2/postgres/orafce

Sun Studio does not like array declarations with null as dimenstion.
So, In pipe.c we have,

typedef struct
{
LWLockId shmem_lock;
pipe *pipes;
alert_event *events;
alert_lock *locks;
size_t size;
unsigned int sid;
char data[]; /* line 149 */
} sh_memory;

A quick look tells me that this should not be hard to fix, but have not
prepared any patch as I dont understand the code very well.
Is it possible to fix this soon ? This will increase the portability and
would help people use orafce with existing pg binaries on Solaris.

Thanks
Mayuresh

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Mayuresh Nirhali (#1)
Re: orafce does NOT build with Sun Studio compiler

Mayuresh Nirhali <Mayuresh.Nirhali@Sun.COM> writes:

Sun Studio does not like array declarations with null as dimenstion.
So, In pipe.c we have,

typedef struct
{
LWLockId shmem_lock;
pipe *pipes;
alert_event *events;
alert_lock *locks;
size_t size;
unsigned int sid;
char data[]; /* line 149 */
} sh_memory;

Most C compilers don't like that either. The standard locution is
something like

char data[1]; /* VARIABLE LENGTH ARRAY */

where you just comment to the human reader that the array is not always
of length 1. This has some implications for sizeof() computations.
There are lots and lots of examples in the existing Postgres code.

regards, tom lane

#3Mayuresh Nirhali
Mayuresh.Nirhali@Sun.COM
In reply to: Tom Lane (#2)
Re: orafce does NOT build with Sun Studio compiler

Tom Lane wrote:

Most C compilers don't like that either. The standard locution is
something like

char data[1]; /* VARIABLE LENGTH ARRAY */

Yes, I tried this already and forgot to mention earlier that with such
patch, I do not see any other errors.
So, this is the only issue with Sun Studio compilation of orafce.

Mayuresh

#4Jonah H. Harris
jonah.harris@gmail.com
In reply to: Mayuresh Nirhali (#3)
Re: orafce does NOT build with Sun Studio compiler

On Thu, Jun 5, 2008 at 2:18 AM, Mayuresh Nirhali
<Mayuresh.Nirhali@sun.com> wrote:

Most C compilers don't like that either. The standard locution is
something like

char data[1]; /* VARIABLE LENGTH ARRAY */

So, this is the only issue with Sun Studio compilation of orafce.

Well, it's likely an issue with most commercial compilers. Accepting
an array of undefined-length in this way is non-standard and is a GCC
extension.

--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com
Edison, NJ 08837 | http://www.enterprisedb.com/

#5Pavel Stehule
pavel.stehule@gmail.com
In reply to: Mayuresh Nirhali (#1)
Re: orafce does NOT build with Sun Studio compiler

Hello

2008/6/5 Mayuresh Nirhali <Mayuresh.Nirhali@sun.com>:

Hello hackers,

During the Oracle migration tutorial by peter at PGCon, I took an action
item for myself to try orafce on Solaris/OpenSolaris.
As pg binaries are bundled with Solaris now (using Sun Studio compiler), I
decided to try out building orafce against the same bundled binaries (with
USE_PGXS=1).

I see following build error,
/opt/SUNWspro/SS11/bin/cc -xc99=none -xCC -KPIC -I.
-I/usr/include/pgsql/server -I/usr/include/pgsql/internal -I/usr/sfw/include
-I/usr/include/kerberosv5 -c -o pipe.o pipe.c
"pipe.c", line 149: null dimension: data
cc: acomp failed for pipe.c
gmake[1]: *** [pipe.o] Error 2
gmake[1]: Leaving directory `/builds2/postgres/orafce/orafce'
*** Error code 2
make: Fatal error: Command failed for target `orafce/config.status'
Current working directory /builds2/postgres/orafce

Sun Studio does not like array declarations with null as dimenstion.
So, In pipe.c we have,

typedef struct
{
LWLockId shmem_lock;
pipe *pipes;
alert_event *events;
alert_lock *locks;
size_t size;
unsigned int sid;
char data[]; /* line 149 */
} sh_memory;

A quick look tells me that this should not be hard to fix, but have not
prepared any patch as I dont understand the code very well.
Is it possible to fix this soon ? This will increase the portability and
would help people use orafce with existing pg binaries on Solaris.

Thanks
Mayuresh

I'll fix it soon

Pavel

Show quoted text

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#6Bjorn Munch
Bjorn.Munch@sun.com
In reply to: Mayuresh Nirhali (#1)
Re: orafce does NOT build with Sun Studio compiler

On 05/06 10.44, Mayuresh Nirhali wrote:

Sun Studio does not like array declarations with null as dimenstion.
So, In pipe.c we have,

typedef struct
{
LWLockId shmem_lock;
pipe *pipes;
alert_event *events;
alert_lock *locks;
size_t size;
unsigned int sid;
char data[]; /* line 149 */
} sh_memory;

Have you tried with Studio 12? I have a vague recollection that it
might treat this differently (in order words, accept it), but I may be
wrong...

- Bjorn

#7Jonah H. Harris
jonah.harris@gmail.com
In reply to: Bjorn Munch (#6)
Re: orafce does NOT build with Sun Studio compiler

On Fri, Jun 6, 2008 at 10:35 AM, Bjorn Munch <Bjorn.Munch@sun.com> wrote:

Have you tried with Studio 12? I have a vague recollection that it
might treat this differently (in order words, accept it), but I may be
wrong...

It may work, but it's still unportable code. Correcting the root
problem is the real fix, and one Pavel seemed to agree with.

--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com
Edison, NJ 08837 | http://www.enterprisedb.com/