Re: Oracle 9i - issues == Deal breaker

On Tue, Sep 16, 2003 at 11:17:21AM -0500, Matt Pavlovich wrote:
> > On Mon, 2003-09-15 at 12:25, Matt Pavlovich wrote:
> > > Any work around for this?  We will not standardize on RH ES if we can't
> > > run Oracle 8 and Oracle 9.
> > 
> > AFAIK, Oracle is committed to certification on RHEL 3 when it is
> > released. Remember that taroon is beta code.
> 
> Taroon being beta has nothing to do with why Oracle 8 and 9 are broken. 
> RH broke backwards compatibility w/ GLIBC, by not exporting the
> __ctype_b, in favor of the localized __ctype_b_loc.  Debian and other
> distributions work just fine.  GLIBC was written with backwards
> compatibility to avoid issues such as this.

This is wrong.
GLIBC maintains backward compatibility only with shared libraries and
binaries, never relocatable objects or archives thereof.
The primary reason for this is how symbol versioning works.
Symbol version is attached to symbols at final link time (either
during shared libraries linking or binary linking), while the layout
of structures and count/type of function arguments is determined
from headers and thus matters at compile time.
This implies that the final link needs to be done against the same glibc
as the relocatable objects (which are linked into the binary/shared library)
were compiled against.
If you compile against glibc 2.1 or even glibc 2.0 and
link against glibc 2.2 or glibc 2.3, there will be lots of problems.
If the glibc differences between compile time glibc and link time glibc
are smaller, the chances things will work are bigger, but if you are
unlucky, you'll hit the difference.

To give an example:
Between glibc 2.1 and 2.2 struct shmid_ds, struct shminfo, struct msqid_ds,
struct semid_ds changed (to avoid 16bit pids among other things).
shmctl@@GLIBC_2.2, semctl@@GLIBC_2.2, msgctl@@GLIBC_2.2 were introduced.
If you compile on glibc 2.1 and link against glibc 2.2 or later,
you'll use the old structure layout but @@GLIBC_2.2 functions, which means
your program will likely misbehave, segfault or whatever (this happened to
some Oracle version too).

__ctype_b is a similar thing.
glibc 2.3 introduced uselocale(3) and other functions for the new locale
model. libstdc++ uses it these days a lot and more and more libraries
will follow RSN. Unfortunately, mixing objects using __ctype_b with
objects using uselocale doesn't really work as expected.

So, if you want to link Oracle binary-only relocatable objects, you need
to link them against the same glibc as Oracle used when compiling them.
Or better yet the binary-only relocatable objects should not use glibc
headers, instead come with their own structures and should call wrappers
around functions they need, which would be shipped in source.

	Jakub


--
Taroon-beta-list mailing list
[email protected]
http://www.redhat.com/mailman/listinfo/taroon-beta-list