Prev: stdin problem.
Next: Where does gdb find source code to display and step through?
From: Casper H.S. Dik on 1 Mar 2010 16:53
Barry Margolin <barmar(a)alum.mit.edu> writes:

>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.

But it wasn't as such; the "HNAME" tells the runtime linker what name
it should open; only SunOS 4.x interpreted the suffix.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: Ersek, Laszlo on 1 Mar 2010 18:20
In article <4b8c30aa$0$10144$426a74cc(a)news.free.fr>,
Nicolas George <nicolas$george(a)salle-s.org> writes:

> 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.

I'd like to mention two (not standardized) environment variables.
LIBRARY_PATH tells where to look for libfoo.so (or libfoo.a) at
executable building time, and LD_LIBRARY_PATH tells the dynamic loader
where to look for libfoo.so.$MAJOR when running the executable (if the
dso is not found on the "runtime library search path" that was
(optionally) set in the executable when it was built).

I like to set C_INCLUDE_PATH, CPLUS_INCLUDE_PATH and LIBRARY_PATH as
well -- for me they are much handier than passing scores of -I and -L
options (especially when fighting configure scripts made with autoconf).

Cheers,
lacos
From: Gordon Burditt on 2 Mar 2010 06:50
>I am using Linux.
>
>Is there a C library function to search along a path to locate a file?

No.

Usually such searches have their own particular requirements that
make a general function not particularly useful. There's just too
many options.

>Supposing I have an environment variable FOOPATH as follows:
>
>BARPATH=/var/test/dir1:/var/test/dir2:/dirdoesnotexist:/home/fooser
>
>I want to open the file foo.txt, which may be located in one of the
>directories in BARPATH.

You can build your own. It's not that difficult.

Use getenv() to get the environment variable.
Use strcpy() and malloc() to create a writable copy of the search path.
Use strtok() to iterate over each directory in the search path.
Use sprintf() to construct a file name.
Check if the file is acceptable (this is where things get sticky).
This may involve stat() on the file, fopen()ing it, reading
parts of it, etc. If so, you've found it, otherwise, try the next directory.

This search doesn't care if the file is missing in some of the
directories (or the directories themselves are missing - that isn't
checked since the information isn't needed).

For shells trying to run something, the "file is acceptable" if it
has at least one x permission bit on (even for root), checked with
stat(), and it looks like something that can be executed.

For files you intend *reading*, the "file is acceptable" probably
if it can be opened for read. And maybe you checked it's not empty.
Careful, someone might switch files on you even if you open it right
away, and it's more likely the longer you wait to open it.

For files you intend *writing*, I don't think the path-search is
appropriate, but someone might insist on it anyway. If you didn't
find it, do you create it? Where? Do you ask "are you Shirley?"
if the file *didn't* exist?

Now, what happens if you find a file that is *NOT* acceptable? (E.g.
no read permission) Abort search with error or keep going? Shells
kept going for an executable file search.


>Is there a library function that will provide that facility, or do I need
>to create a buffer, and start slicing and splicing the pathname and filename
>from within my program?

I'm not sure where you have to "slice", but splicing with sprintf()
isn't that hard.

>This is a core program, so /usr/lib may not yet be mounted when the search
>takes place, so ideally a function from a library normally found in the /lib
>directory is preferred.
>
>Also, some directories within BARPATH may not yet exist. Will the library
>function skip over the non-existent ones?
From: Lew Pitcher on 14 Mar 2010 13:08
On Mar 1, 2:12 pm, Ramon F Herrera <ra...(a)conexus.net> wrote:
> 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.

Maybe. But then again, the Linux bash(1) and builtins(7) manpages make
no mention of it. Additionally, /bin/which and /usr/bin/which exist,
and are (or claim to be) POSIX shell scripts.

>  > 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: Ersek, Laszlo on 14 Mar 2010 13:37
In article <f046ee36-006a-4a1d-ab92-728531d5be84(a)z4g2000yqa.googlegroups.com>, Lew Pitcher <lpitcher(a)teksavvy.com> writes:
> On Mar 1, 2:12=A0pm, Ramon F Herrera <ra...(a)conexus.net> wrote:
>> On Mar 1, 2:08=A0am, 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.
>>
>> =A0> On my system which is a shell script.
>>
>> On most systems it is a shell built-in.
>
> Maybe. But then again, the Linux bash(1) and builtins(7) manpages make
> no mention of it. Additionally, /bin/which and /usr/bin/which exist,
> and are (or claim to be) POSIX shell scripts.

I'd risk that y'all are looking for "command -v".

lacos
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: stdin problem.
Next: Where does gdb find source code to display and step through?