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
http://fedoraproject.org/wiki/UnderstandingDSOLinkChange. 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).
-Angus
-A
Fabio
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
