Re: Windows and DLLs

[Tim Moore <tmoore tembel org>]

David Jeske wrote:
> 
> On Sun, Oct 04, 1998 at 07:21:22PM -0400, John Kodis wrote:
> > On Sun, Oct 04, 1998 at 11:42:05AM -0700, David Jeske wrote:
> > >
> > > On Sun, Oct 04, 1998 at 12:10:57PM +0200, Nils Philippsen wrote:
> > > > > We would be 'best off' if we could ask the system for the full path to
> > > > > the executable which was 'exec()ed' into our process.
> > >
> > > I think this should be a Gnome API. We're not going to be changing
> > > POSIX. That way we can implement as best we can for each system, and
> > > if anyone puts it into their kernels, we can implement it with that.
> >
> > After some poking around, I noticed that Linux (at least the 2.1.120
> > release) offers such a mechanism already if the /proc filesystem is
> > built into the kernel.
> >
> > $ ls -l /proc/self/exe
> > lrwx------   1 kodis  kodis   0 Oct  4 19:13 /proc/self/exe-> /bin/ls*
> 
> I looked into this a bit more carefully, and at least on my system,
> this is not a 'standard' symbolic link, in that it gives back the
> inode number, not the string 'path'. This makes it difficult to get
> the full path of the executable back.

[snip]

That's how it is on my system, too. But all is not lost. libgtop
actually has a mechanism for finding the filenames for a given inode. On
systems (such as Linux) which support that directly (through /proc in
this case) it uses that. On other systems, it actually builds a database
(actually several -- one system-wide and per-user) and looks them up in
that.

This also solves the hard link problem, since I don't think hard links
can be resolved like symlinks as suggested.

I didn't see any specific mechanism in libgtop for accessing
/proc/self/exe.

Tim