[Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
Gordon Messmer
notifications at github.com
Mon Feb 6 06:30:49 UTC 2023
@gordonmessmer commented on this pull request.
> +/*
+ * Rather than re-implement path searching for shared objects, use
+ * dlmopen(). This will still perform initialization and finalization
+ * functions, which isn't necessarily safe, so do that in a separate
+ * process.
+ */
+static char *getLibtoolVerFromShLink(const char *filename)
+{
+ char dest[PATH_MAX];
+ int pipefd[2];
+ pid_t cpid;
+
+ if (pipe(pipefd) == -1) {
+ return NULL; // Should this be a fatal error instead?
+ }
+ cpid = fork();
When dlopen() loads a library, it runs functions with the __attribute__((constructor)) function attribute, and when they are closed, it runs functions with __attribute__((destructor)).
This isn't always safe. Some libraries (like gobject) do no support being opened and closed, and they'll result in a SEGV if they're opened more than once. That will happen if elfdeps examines a shared object that is linked to gobject, and then later another one (or libgobject itself).
However, if we fork and then open only one shared object and then exit, we don't cause that problem.
dlopen() isn't a perfect mechanism for resolving the name of a shared object to its path for that reason, but the alternatives are either parsing the output of ldd (which seems an awful lot like forking and dlopen() an object with more steps) or re-implementing the search algorithm in glibc/elf/dl-load.c:_dl_map_object(), and I dislike those options more, personally.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#discussion_r1096987384
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/pull/2372/review/1284610720 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20230205/5344a881/attachment.html>
More information about the Rpm-maint
mailing list