Re: [Tora-develop] Testing tora3 svn

[<iv...@cv...>]

Quoting iv...@cv...:

> Quoting Nathan Neulinger <nn...@ne...>:
>
>> This is why I came up with the "stub" oracle DLL for the windows build.
>>
>> I wonder if it would be possible to do the same for linux?
>>
>> Create a stub .so that satisfies the link dependency, and installs
>> as a separate rpm/package, but can be removed if the
>> user installs the actual oracle client.
>>
>
> I think this is good idea - especially for Linux.
> On Windows you can freely tell users to download proprietary drivers,
> and they will not crucify you.
>
> Unlike to OCCI, the OCI API?is very stable. It is pure C, it's
> backward compatible,
> without any RTTI, virtual method table, Exceptions etc.
>
> The only dangerous point could be macro definitions for datatypes
> (bool vs. boolean vs. Boolean).
> Some possible calling conventions glitches(__attribute__)
> And OpenVMS?(K-R?C Compiler) compatibility. Many due to backward
> compatibility needs many library symbols
> have names only 8 chars long (lowercase). And names like
> "OCIServerAttach" are just a #define macros.

I just forgot to mention. The issues with ABI differences are VERY
hard to investigate. You have to open Linux GCC 64bit ABI?reference
and go register by register (or byte by byte) and track values for  
differences.

Moreover Oracle is not compiled using gcc but using icc. This makes  
even gdb confused.

> On the other hand such "fake" library would be necessary only at   
> compile time.
> We do not have to redistribute it at all. Only Oracle connection
> provider plugin(poracle) depends on libclntsh.so,
> and the whole application can start without it.
>
> Ivan
>


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.