Re: build of 7.2.1 on SCO Openserver and Unixware 7.1.1
От | Nicolas Bazin |
---|---|
Тема | Re: build of 7.2.1 on SCO Openserver and Unixware 7.1.1 |
Дата | |
Msg-id | 004001c1d5df$9cfdb320$660d090a@software.ingenico.com.au обсуждение исходный текст |
Ответ на | Re: build of 7.2.1 on SCO Openserver and Unixware 7.1.1 (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Bruce Momjian" <pgman@candle.pha.pa.us> Cc: "Nicolas Bazin" <nbazin@ingenico.com.au>; "PostgreSQL-development" <pgsql-hackers@postgresql.org> Sent: Thursday, March 28, 2002 2:30 AM Subject: Re: [HACKERS] build of 7.2.1 on SCO Openserver and Unixware 7.1.1 > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Yes, the patch replaces pow(8,*) with a lookup table of 4 8^X values. > > So SCO provides a library you can't link to? Or you can't mix *.so > > libraries and static *.a libraries? I am inclined ot add this patch to > > the doc/FAQ_SCO file. We really try to avoid major code uglyness to > > work around operating system things that should work on their own. > > Actually, the existing coding in odbc is just plain stupid: why are we > using a transcendental function call to emulate an integer shift? > Even the table-based implementation that Nicolas proposed is doing it > the hard way. Try converting, eg, > > for (i = 1; i <= 3; i++) > y += (s[i] - 48) * (int) pow(8, 3 - i); > > to > > for (i = 1; i <= 3; i++) > y += (s[i] - '0') << (3 * (3 - i)); > > and you can get the patch accepted just on efficiency and readability > grounds, never mind whether it avoids SCO library breakage. > > >> The TCL stuff is because Caldera distribution of TCL is compiled with their > >> compiler. If you happen to use another compiler on your platform (gcc) it > >> doesn't work anymore. Caldera compiler has -belf -Kpic options which are > >> fully incompatible with gcc. That's why I though best to leave the TCL > >> packages been compiled with the compiler used for postgresql. > > We've been around on this a couple of times now; the current theory is > that we should stop using the TCL-supplied switches altogether. There > is a patch in the works to change libpgtcl and pltcl to be built the > same way we build everything else in the distribution. Perls modules have the same problems. Is there a patch also ? > > regards, tom lane > >
В списке pgsql-hackers по дате отправления: