Re: Add a common library

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On 02/20/2012 01:48 AM, Fabio M. Di Nitto wrote:
> On 2/20/2012 5:47 AM, Angus Salkeld wrote:
>> On 17/02/12 08:22 +1100, Angus Salkeld wrote:
>>> On 16/02/12 16:04 +0100, Fabio M. Di Nitto wrote:
>>>> On 2/16/2012 3:58 PM, Vladislav Bogdanov wrote:
>>>>> 16.02.2012 14:50, Fabio M. Di Nitto wrote:
>>>>>> On 2/16/2012 12:36 PM, Jan Friesse wrote:
>>>>>>> Fabio M. Di Nitto napsal(a):
>>>>>>>> On 2/8/2012 9:41 PM, Steven Dake wrote:
>>>>>>>>> On 02/08/2012 12:27 PM, Fabio M. Di Nitto wrote:
>>>>>>>>>> On 2/8/2012 8:19 PM, Steven Dake wrote:
>>>>>>>>>>>> Assuming you are upgrading from version X to X+1, the symbols
>>>>>>>>>>>> will
>>>>>>>>>>>> simply move from static inline to the share object. Specially
>>>>>>>>>>>> in this
>>>>>>>>>>>> case where the application is not affected directly.
>>>>>>>>>>>> application -> libfoo (with static inline)
>>>>>>>>>>>> application -> libfoo -> libcommon
>>>>>>>>>>>> Even in a downgrade case, libcorosync_common would not be
>>>>>>>>>>>> referenced by
>>>>>>>>>>>> any of the libraries.
>>>>>>>>>>>> I don´t have a strong opinion here, but I would prefer to
>>>>>>>>>>>> have it a
>>>>>>>>>>>> shared lib. We had some nasty issues with static before (ask
>>>>>>>>>>>> Jan how
>>>>>>>>>>>> long it took for him to debug that handle_ corruption when
>>>>>>>>>>>> linking
>>>>>>>>>>>> static).
>>>>>>> Hey, that handle_ thing was *real* pain. Took like week (40 hours) of
>>>>>>> extra hard work.
>>>>>> Exactly.... :)
>>>>>> [BIG FAT SNIP]
>>>>>>>> You also need to take into account that not all distribution ship
>>>>>>>> all
>>>>>>>> libraries in one package (corosynclib vs libcpg4 libquorum4). So
>>>>>>>> it´s
>>>>>>>> not that uncommon as you might think and it leaves a window open for
>>>>>>>> lots of headaches.
>>>>>>>> You make your call, but static is bad vs a very small pain to get
>>>>>>>> applications linked correctly (as they should be) and pkg-config
>>>>>>>> can be
>>>>>>>> used to ease the pain (tho i am still not sure we should enforce
>>>>>>>> linking
>>>>>>>> with -lcorosync_common since not all applications use symbols
>>>>>>>> from it).
>>>>>>> Ok, it looks like I've misunderstood
>>>>>>> So as
>>>>>>> long as
>>>>>>> it works as you said (app using lcpg, but not cs_errorstr DON'Tt
>>>>>>> need to
>>>>>>> link with -common), then shared link solution seems to be better.
>>>>>>> But if
>>>>>>> it doesn't work (ie. lcpg linked with lcommon, app need to link with
>>>>>>> both), static approach is better.
>>>>>> I have tested both F16 and rawhide about the same way but by all mean,
>>>>>> we can give it another test round.
>>>>>>> Also I don't see reason for pkg-config to include -lcommon.
>>>>>>> So one question is, where made Angus mistake so DSO warning appeared
>>>>>>> (and whole this thread started)?
>>>>>> I can´t say for sure without doing the exact same build, but with the
>>>>>> branch he published in topic-commonlib, it was working fine.
>>>>>> He probably forgot to link libcpg with libcorosync_common shared at
>>>>>> that
>>>>>> stage of testing. The only way to know would be to see ldd libcpg
>>>>>> in his
>>>>>> system.
>>>>>> Angus, is it an option for you to revalidate my testing? It´s no point
>>>>>> for me to do it all over again. We need a 3rd party to look at it :)
>>>>> Sorry for stepping in, but that is absolutely true for new fedora
>>>>> systems (from that point where indirect linking was prohibited), that
>>>>> you need to link app against lib *only* if you use symbols from that
>>>>> lib
>>>>> directly in app (including calls from inline functions defined in
>>>>> "foreign" header files, may be that was the reason of that warning?).
>>>> That´s what my test did show :) but apparently Angus still got somekind
>>>> of error during his tests. The point remains that I cannot repeat Angus
>>>> test but he can validate the tests i did :)
>>>>> You *do not* need to link against the whole stack of libs which are
>>>>> used
>>>>> indirectly, but whose symbols you do not reference.
>>>> Exactly. see previous emails in this thread.
>>> I'll give it a go today and let you know.
>> So the reason my test failed was that I patched testcpg to directly
>> call one of those error functions. That makes sense given what Fabio
>> has explained.
>> So can we go ahead with the .a -> .so or are we sticking to the static
>> lib? (I vote for .so).
> Just for the record, .so pretty please with a spoon of sugar and love :)

I am not hot on shared object, but really have lost interest in this topic.

Honza should make the final decision since he will be maintaining what
comes out for some time.


> Fabio
> _______________________________________________
> discuss mailing list
> discuss@xxxxxxxxxxxx

discuss mailing list

[Corosync Project]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

Add to Google Powered by Linux