ovis
ovis copied to clipboard
ovis-hpc
library location discussion
This is a longer-term suggestion, not something that needs to be implemented in the next few weeks. I just want to capture the thought for future implementation.
There are some libaries like "parse_stat" (perhaps about to be renamed libldmsd_parse_stat), that are currently installed and exported to users external to the ldms tree. These wind up installed in places like /usr/lib. I might make sense to instead put these under a sub-directory named something like "/usr/lib/ldmsd".
Some of these libraries are clearly only meant to be internally used (e.g. they don't have installed headers, their function names are too generic for use outside the project tree).
But since they are dynamically linked by some plugins, they need to be in a discoverable lib path. To make our /usr/lib/ldmsd discoverable, we could add an ldms conf file into /etc/ld.so.conf.d.
Another possibility is to make libraries like these statically linked convenience libraries, but there was some push back on that approach.
Are you suggesting $libdir/ldmsd still needs to be separate from the existing $pkglibdir (by convention $libdir/ovis-ldms) even after we have made sure anything installed by us in $libdir has been renamed $libdir/libldms_* or $libdir/libovis_*?
It certainly could be $pkglibdir. It would just be nice to put things that are not intended for external use somewhere other than $libdir.
Could you take a look at a sos install (one of the requires for the ldms sos store) libdir deposits and suggest a list of what should be in the corresponding pkglibdir rather than $libdir?
@baallan, well, I know very little about sos and its intent, so that is difficult to say at look. But I can give my first impression, and if you fill me in on the intent in places, I can perhaps provide more informed advice.
It looks like there are two libraries off the bat that look normal, libsos and libods (I assume that with so few letters, someone has already checked that these names don't conflict with other known libraries). Assuming that they are intended to be accessed by projects outside of the sos tree, then putting those in $libdir looks correct. ldms's sos store is part of a project external to sos, and it looks like that links agains "-lsos", so yes, that confirms that libsos should be in $libdir.
The many libidx_ and libkey_ libraries in sos/ods/src are where my warning alarm starts going off. If understand correctly, these are plugins for ods and not intended to be used by external packages. The name of the libraries does not suggest an intent for global install, and they look like plugins for ods. So I would think they probably should be changed from $libdir to $pkdlibdir.
But, again, if my initial guess at intent from a scan of the source tree was wrong, that could change my recommendation.
Are there any libraries in there that I completely missed?
Let me net this out; the SOS library names are not collision friendly. I would like to put them all under a subdirectory, e.g. 'sos' or something else.
I would like to build libsos, libods,libods_idx, into a single library. The others are plugins, i.e. loaded with dlopen().
I am happy to hear any and all suggestions on how to hide this beast.
Tom
On Thu, Nov 14, 2019 at 1:03 PM Christopher J. Morrone < [email protected]> wrote:
@baallan https://github.com/baallan, well, I know very little about sos and its intent, so that is difficult to say at look. But I can give my first impression, and if you fill me in on the intent in places, I can perhaps provide more informed advice.
It looks like there are two libraries off the bat that look normal, libsos and libods (I assume that with so few letters, someone has already checked that these names don't conflict with other known libraries). Assuming that they are intended to be accessed by projects outside of the sos tree, then putting those in $libdir looks correct. ldms's sos store is part of a project external to sos, and it looks like that links agains "-lsos", so yes, that confirms that libsos should be in $libdir.
The many libidx_ and libkey_ libraries in sos/ods/src are where my warning alarm starts going off. If understand correctly, these are plugins for ods and not intended to be used by external packages. The name of the libraries does not suggest an intent for global install, and they look like plugins for ods. So I would think they probably should be changed from $libdir to $pkdlibdir.
But, again, if my initial guess at intent from a scan of the source tree was wrong, that could change my recommendation.
Are there any libraries in there that I completely missed?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ovis-hpc/ovis/issues/89?email_source=notifications&email_token=ABVTPXDMOMCJNFXT5SGGCXLQTWOIDA5CNFSM4JMPOIK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEC5WSQ#issuecomment-554031946, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVTPXAJXFIKVOWQ36JN6S3QTWOIDANCNFSM4JMPOIKQ .
-- Thomas Tucker, President, Open Grid Computing, Inc.
Building libsos, libods, and libods_idx into one library for external consumption and putting it in $libdir sounds fine to me. Putting the plugins that are loaded with dlopen() in a subdirectory of $libdir (e.g. $pkglibdir) sounds like a good way to go.
But keep in mind I am flying at the 10,000 ft level for sos right now. I didn't really dig into the code, I just looked at overall structure.
@tom95858 should we open a request on the sos tracker to build libsos, libods,libods_idx, into a single library and have all the plugins in pkglibdir? Or just leave it here? Sounds like everyone is happy with plugins in pkglibdir as a good cleanup.
Hi @baallan, @morrone. I agree with this change. Something like this:
$pkglibdir/sos/libsos.so $pkglibdir/sos/plugins/...
If all agree, I'll make it so...
@tom95858 , It is not clear to me why you would move libsos.so to a subdirectory. If you do that, you also need to add an ld.so.conf.d file so that "-lsos" works. And at that point, "-lsos" is still going to conflict if there is some other libsos out there. If you are worried about name collision, the library needs a better name (libovissos, or something like that).
Also, it would be nice if this discussion moved to a sos ticket, because the sos discussion is taking over this ticket's goal of discussing the location of ldms libraries.