@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();
There is a brief comment before getLibtoolVerFromShLink, but I can move it or
expand it with more detail, at your preference.
Note: The problem does occur when processing a single file, because this new
process is calling dlopen() on each object in the dynamic table of the file
being processed. So, if a file is linked to libsoup3, for example, elfdeps
will dlopen() libsoup and then later dlopen() libgobject. Each handle is
passed to dlinfo() and then the resulting linkmap->l_name is processed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#discussion_r1097010807
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/pull/2372/review/1284648...@github.com>_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
