Prev: stdin problem.
Next: Where does gdb find source code to display and step through?
From: Jens Thoms Toerring on 1 Mar 2010 05:03
In comp.unix.programmer Mark Hobley <markhobley(a)hotpop.donottypethisbit.com> wrote:
> In comp.unix.programmer Ramon F Herrera <ramon(a)conexus.net> wrote:
> > An educated guess is that what you want is too specialized. The most
> > you could find is a path splitter.

> I am shocked that there is no path walker. A path splitter would be of some
> help, if there is one.

There's always the strtok() function. Use getenv() to get the string
associated with the environment variable, make a copy of the string
(don't use the string you got from getenv(), strtok modifies its
argument and that would change the environment variable if applied
directly), and then use strtok() to take the string apart at ':'
characters. That should give you the paths, one after another.

Regards, Jens
--
\ Jens Thoms Toerring ___ jt(a)toerring.de
\__________________________ http://toerring.de
From: Nicolas George on 1 Mar 2010 05:14
Barry Margolin wrote in message
<barmar-DA609D.22344928022010(a)news.eternal-september.org>:
> LD_LIBRARY_PATH allows for a variety of suffixes because of version
> numbers.

Actually, LD_LIBRARY_PATH lookup does not care about the suffix at all, it
just searches for the required file as described in the NEEDED field:

ssecem /tmp $ mkdir some_directory
ssecem /tmp $ gcc -shared -Wl,-soname,silly_name_no_suffix \
-o some_directory/libsilly.so -x c /dev/null
ssecem /tmp $ gcc -L some_directory -lsilly -x c - <<\EOF
int main(void) { return 0; }
EOF
ssecem /tmp $ objdump -p a.out | grep NEEDED
NEEDED silly_name_no_suffix
NEEDED libc.so.6
ssecem /tmp $ LD_LIBRARY_PATH=/tmp/some_directory strace ./a.out |& grep some
open("/tmp/some_directory/tls/x86_64/silly_name_no_suffix", O_RDONLY) = -1 ENOENT (No such file or directory)
<snip similar lines>
From: Ramon F Herrera on 1 Mar 2010 13:12
On Mar 1, 2:08 am, markhob...(a)hotpop.donottypethisbit.com (Mark
Hobley) wrote:
> In comp.unix.programmer Ramon F Herrera <ra...(a)conexus.net> wrote:
>
> > An educated guess is that what you want is too specialized. The most
> > you could find is a path splitter.
>
> I am shocked that there is no path walker. A path splitter would be of some
> help, if there is one.
>
> > I was about to suggest the OP to take a look at the program
> > "which.exe", Barry.
>

> On my system which is a shell script.

On most systems it is a shell built-in.

> I wonder if there is a C implementation of it though ...

Yes, there is. Right here:

http://gnuwin32.sourceforge.net/packages/which.htm

-Ramon

From: Barry Margolin on 1 Mar 2010 16:02
In article <4b8b9387$0$16642$426a74cc(a)news.free.fr>,
Nicolas George <nicolas$george(a)salle-s.org> wrote:

> Barry Margolin wrote in message
> <barmar-DA609D.22344928022010(a)news.eternal-september.org>:
> > LD_LIBRARY_PATH allows for a variety of suffixes because of version
> > numbers.
>
> Actually, LD_LIBRARY_PATH lookup does not care about the suffix at all, it
> just searches for the required file as described in the NEEDED field:

Maybe it depends on the OS. In my Solaris days, shared objects had a
major version number in the suffix.

>
> ssecem /tmp $ mkdir some_directory
> ssecem /tmp $ gcc -shared -Wl,-soname,silly_name_no_suffix \
> -o some_directory/libsilly.so -x c /dev/null
> ssecem /tmp $ gcc -L some_directory -lsilly -x c - <<\EOF
> int main(void) { return 0; }
> EOF
> ssecem /tmp $ objdump -p a.out | grep NEEDED
> NEEDED silly_name_no_suffix
> NEEDED libc.so.6
> ssecem /tmp $ LD_LIBRARY_PATH=/tmp/some_directory strace ./a.out |& grep some
> open("/tmp/some_directory/tls/x86_64/silly_name_no_suffix", O_RDONLY) = -1
> ENOENT (No such file or directory)
> <snip similar lines>

--
Barry Margolin, barmar(a)alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Nicolas George on 1 Mar 2010 16:24
Barry Margolin wrote in message
<barmar-79E37F.16022801032010(a)news.eternal-september.org>:
> Maybe it depends on the OS. In my Solaris days, shared objects had a
> major version number in the suffix.

Yes, but that is a convention, like calling your tar files .tar (tar does
not care about the filename), and unlike the lib*.a files (-lfoo looks for
libfoo.a, not libfoo.b).

The exact process for ELF systems, including Solaris, is:

* When building the executable:

- if the argument is -lfoo, look for libfoo.so (and if it is not found,
fall back to static linking, looking for libfoo.a);

- if the argument is a filename, use it directly;

- look for a SONAME field in the file header and use it;

- if there is no SONAME field, use the base name of the file name;

- put the resulting SONAME in the NEEDED field.

* When running the executable:

- look for the NEEDED fields,

- find the file.

The only part that requires a specific suffix is the lookup -lfoo ->
libfoo.so. The rest is convention.

Most of the time, you will have:

- libfoo.so.$MAJOR.$MINOR
-> actual plain file containing the library
-> contains "libfoo.so.$MAJOR" in its SONAME field
-> never accessed directly when running programs

- libfoo.so.$MAJOR.$OLDER_MINOR
-> same as above

- libfoo.so.$MAJOR
-> symlink to libfoo.$MAJOR.$MINOR with the highest $MINOR.
-> may have been created automatically by library management tools like
ldconfig (scanning for plain files and reading the SONAME field)
-> accessed when running programs, because they have libfoo.so.$MAJOR in
the NEEDED field

- libfoo.so.$OLDER_MAJOR.$OTHER_MINOR
-> actual plain file containing an older version of the library

- libfoo.so.$OLDER_MAJOR
-> symlink to libfoo.so.$OLDER_MAJOR

- libfoo.so
-> symlink to libfoo.so.$MAJOR or libfoo.so.$MAJOR.$MINOR
-> must be a link to the same version as the .h files in include
-> normally created when the headers are installed
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: stdin problem.
Next: Where does gdb find source code to display and step through?