@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/1284610...@github.com>_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
