Le lun. 17 juin 2019 à 02:01, Paul Smith <p...@mad-scientist.net> a écrit :
> On Sun, 2019-06-16 at 21:42 +0200, Eric Noulard wrote: > > Le dim. 16 juin 2019 à 18:26, Paul Smith <p...@mad-scientist.net> a > > écrit : > > > But, that's not the only way to use shared libraries. I'm trying > > > to collect a number of static libraries with different interfaces > > > into a single shared library that can be linked with executables. > > > > Correct me if I'm wrong but I guess that if your goal is to "collect" > > all those static libs *into* a shared lib then what you need is to > > make your STATIC libs, OBJECT libs and then I think you'll get what > > you expect. > > Yep, I'm familiar with OBJECT libs and if I could use them they would > give the correct behavior, you're right. Unfortunately it's not the > case that OBJECT libraries are completely "drop-in" replaceable for > STATIC libraries, and they cannot be substituted in my environment. > > See, for one example: > https://gitlab.kitware.com/cmake/cmake/issues/19388 > > I am not able to rework my system comprehensively enough to remove all > mutual references between all my current libraries. And there are > other issues where OBJECT libraries aren't the equivalent of STATIC > libraries. > Yes right. > > Otherwise (at least in the way CMake currently works) any symbols > > defined in foo.a STATIC lib will *stay* in it. So in the end when you > > link an executable using bar.so SHARED lib only (which is using > > foo.a) then you won't have the symbol you need from foo unless foo.a > > is added to the link line ? Am I right? > > No, that's not right. > > The visibility of symbols depends on how your code is compiled and has > nothing to do with cmake and whether cmake links into a shared or > static library. > > On POSIX systems (gcc and clang), all symbols are public by default > regardless of whether you are compiling them for a static or shared > library. > > On Windows it's all more complicated, but in my situation I've added > the WINDOWS_EXPORT_ALL_SYMBOLS property to my libraries. > Yes you are right and I know that, but AFAIK when (with CMake) you TLL a shared lib to a static lib. You do not end up with any of the static lib symbol in the shared lib. At least none of them are visible with nm. (I did only test that on Linux). > But how can you do that without either: > > > > 1) adding the static lib to any link line (including the one using bar) > > 2) *merging* foo.a *into* bar.so which should be what you achieve by > > making foo an OBJECT lib. > > I'm not sure what you mean by "merging foo.a into bar.so": you can't > merge something into a shared library any more than you can merge > something into an executable. By putting "foo" into the TLL of "bar", > I've added the static library to the creation of the shared library: > > cc -shared -o bar.so bar.o libfoo.a > > Now when bar.so is created it will have the required contents of > libfoo.a in it. > You mean that the part of libfoo.a which is actually used by some part of bar.o gets in bar.so or any [exported] symbol found in libfoo.a gets in bar.so with the same export rule? My test showed me something different but I'll check again, I must have done something wrong. > > If we can agree on that, then using the current rules of CMake > > > inheritance this implies that we can NEVER add a static library as > > > a PUBLIC TLL for a shared library. > > > > Exactly my point. I understand what you say, but if ever CMake was > > doing that you simply couldn't switch (GLOBALLY) from SHARED to > > STATIC using > > https://cmake.org/cmake/help/v3.14/variable/BUILD_SHARED_LIBS.html > > is a single SHARED lib was explicitely specified. > > I wasn't familiar with that option, but I don't think it makes a > difference whether the libraries are made SHARED via this option or > whether they are made SHARED via direct specification: the behavior is > the same. > > > My opinion is that CMake may handle TLL(SHARED STATIC) differently > > than TLL(SHARED SHARED) but forbidding the first would be a major > > headache when you want to go from STATIC to SHARED lib one step after > > another (I have a concrete example in mind in a legacy project). > > I didn't say it should be forbidden!! > > I said that as cmake is currently implemented it doesn't make sense to > do it, implying that cmake might want to change its behavior in this > area to be more useful. > OK now I get your point, thank you for clarifying. > However, after more investigation I see that I was wrong about how > linkers resolve symbols at least in POSIX systems (I'm not sure about > DLLs on Windows... I haven't gotten there yet). > > For some reason I remembered that a linker would prefer symbols found > in static libraries over those found in shared libraries, but in fact > the linker will always choose the implementation of the symbol in the > first library it's defined in regardless of the type of library. > Yes that's right, note however that this behavior may vary between linkers (GNU ld, gold, llvm LLD, ...) as their respective speed: See e.g. https://lld.llvm.org/#performance I know that LLD advertise to be a "drop-in" replacement for ld but I have some nasty legacy project example which show this to be wrong, but that another story. > So, as long as the shared library appears first on the link line it > shouldn't matter that the static library also appears there. > > I still think it's incorrect to add the static library to the link > line, but (at least for linkers with semantics as above) it probably > doesn't actually hurt anything. > This may be true w.r.t. the semantic, but it may (from my experience) vary concerning the link performance, but again this is another subject. If there is effectively no need to have static lib on the line because a shared lib depending on this static lib was already linked to it, then it ought to be suppressed and not rely on some linker policy to tidy up the whole set of shared and static libs. -- Eric
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
