[CMake] linking static libs into shared libs on Linux
Dan Kegel
dank at kegel.com
Wed Jul 8 13:29:51 EDT 2015
So maybe the yasm source needs to have a keyword or two
added to select PIC addressing mode?
Random googling finds suggestions at
http://cvs.tortall.net/pipermail/bug-yasm/2011-October/000086.html
On Wed, Jul 8, 2015 at 10:11 AM, Steve Borho <steve at borho.org> wrote:
> On 07/07, Dan Kegel wrote:
>> On Tue, Jul 7, 2015 at 2:25 PM, Steve Borho <steve at borho.org> wrote:
>> > We're already adding -fPIC to the compile flags for the two object
>> > libraries. This way one set of objects can be used to output the shared
>> > library and the static library. So the C++ files are already compiled
>> > with -fPIC. It is only a problem when we need to link a static library
>> > from one build into the shared library of another build. The static
>> > library itself no longer supports PIC.
>>
>> Really? I didn't think ar was in the habit of modifying machine code like that.
>>
>> At this point maybe the thing to do is make a toy example that reproduces
>> the problem. (Ideally something truly stipped down, like
>> https://github.com/dankegel/winezeug/tree/master/cmake_examples/ex7 )
>
> This rings a bell for me. We encountered this link failure once before.
> A little back history:
>
> Our project has two main source folders, common/ and encoder/, each with
> its own CMakeLists file. Originally we built each folder into a static
> library and then the root level CMakeLists file linked them into a
> shared library, static library, or executable.
>
> This broke when we introduced yasm-compiled assembly objects into the
> common/ folder. We begain getting these same exact PIC errors when
> trying to link the static common.lib and encoder.lib into libx265.so.
> And this is when we were forced to use cmake's object libraries. Now
> common/ and encoder/ generate object libraries and the root level
> CMakeLists links those objects into the final targets and this seemed to
> work ok.
>
> So the yasm objects are somehow the root cause.
>
> --
> Steve Borho
More information about the CMake
mailing list