Thanks Owen, I really appreciate your effort. I did pick up a book on CMake
last night and found how to add a MODULE target to the CMakeLists.txt file.
It’s nowhere near perfect, but I do get a .so out of the deal, so that’s
progress.
I think my real problem may be the third party packages that are included in
the project. Those packages (or at least some of them) seem to be built
without -fPIC (no .so files). I’ve started building my own versions of things
like protobuf and it’s going ok now. This is all less scary to me today so I’m
able to make at least some progress.
— Korry
> On Jan 17, 2019, at 4:28 PM, Owen O'Malley <[email protected]> wrote:
>
> I've filed ORC-460 <https://issues.apache.org/jira/browse/ORC-460> to add a
> switch to build shared libraries. Let me take a first pass at it.
>
> .. Owen
>
>
> On Tue, Jan 15, 2019 at 12:31 PM Korry Douglas <[email protected]
> <mailto:[email protected]>> wrote:
> I think your reply means that I am stuck…. my project must be a shared object
> (it’s an extension to PostgreSQL that is dynamically loaded as needed).
>
> Is that correct? Is there anything I can do to help build shared libraries?
>
> Thanks.
>
> — Korry
>
>> On Jan 15, 2019, at 12:48 PM, Owen O'Malley <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> The current c++ build forces static libraries, based on my previous painful
>> experience with shared libraries on distributed systems. That said, going
>> forward the automated configuration tools are much better. I'd we want to
>> enable shared libraries, we can do that.
>>
>> .. Owen
>>
>> On Jan 15, 2019, at 10:10, Korry Douglas <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>> Thanks for the quick reply, Zhiyuan.
>>>
>>> I’ve tried your suggestion (that was how I expected the process to work),
>>> but I get an error when I do that:
>>>
>>> /usr/local/lib/libprotobuf.a(arena.cc.o): relocation R_X86_64_TPOFF32
>>> against symbol `_ZN6google8protobuf8internal9ArenaImpl13thread_cache_E' can
>>> not be used when making a shared object; recompile with -fPIC
>>>
>>> So the link fails. (I *do* compile my .cc files with -fPIC.)
>>>
>>>
>>> — Korry
>>>
>>>> On Jan 15, 2019, at 10:02 AM, Zhiyuan Dong <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> This my personal $0.02.
>>>>
>>>> I have been able to use the default settings there building various
>>>> supporting *.a files in linux Ubuntu and CentOS. Then I build C++
>>>> functions into my own written *.so file which is then linked to various
>>>> *.a files... And the *.so that calls the orc functionalities in C++ works
>>>> fine.
>>>>
>>>> Hope this helps a little bit.
>>>>
>>>> Zhiyuan
>>>>
>>>> On Tue, Jan 15, 2019 at 8:40 AM Korry Douglas <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>> As an alternative - is there somewhere I can find binary packages for
>>>> liborc (RPMs) ?
>>>>
>>>> — Korry
>>>>
>>>> > On Jan 14, 2019, at 7:17 PM, Korry Douglas <[email protected]
>>>> > <mailto:[email protected]>> wrote:
>>>> >
>>>> > Hi all, I am trying to build a shared library that links to liborc (the
>>>> > C++ API). However, the Makefiles are all set up to build .a files
>>>> > instead of .so files.
>>>> >
>>>> > I’ve figured out how to modify the CMakeLists.txt file to add the -fPIC
>>>> > CFLAG (although I don’t really like editing that file by hand).
>>>> > However, there are many related libraries that seem to be downloaded
>>>> > from various URL’s and those libraries are not compiled with -fPIC.
>>>> >
>>>> > Any suggestions? Thanks in advance.
>>>> >
>>>> > — Korry
>>>>
>>>>
>>>>
>>>> --
>>>> Zhiyuan Dong, Ph.D.
>>>
>
