Dne 20.2.2012 14:07, Steven Dake napsal(a):
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
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).
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.
Shared object seems to be better solution, so let's go with them.
Honza
Regards
-steve
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
