Re: compile+link Fujitsu Linux

On Fri, 1 Feb 2008 13:24:40 -0800 (PST), Richard <riplin@xxxxxxxxxxxx> wrote:

On Feb 1, 9:13 pm, Robert <n...@xxxxxx> wrote:
On Thu, 31 Jan 2008 21:02:58 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:
On Feb 1, 4:33 pm, Robert <n...@xxxxxx> wrote:
On Thu, 31 Jan 2008 09:48:48 -0800 (PST), charles.good...@xxxxxxx wrote:
Thanks for the tips.
Yes I needed to add my curent directory to LD_LIBRARY_PATH
I also nneded to add "-L./" to the cobol command to compile the main
program.

-L is used to override the user's LD_LIBRARY_PATH. It shouldn't be necessary on your own
machine.

Geez, Robert, yet more misinformation. You are _WRONG_ yet again. ld
does _NOT_ follow the LD_LIBRARY_PATH. It follows the LIBPATH. You can
add the current directory to LIBPATH or use the -L _IF_ you want to
link the dynamic libraries statically.

I actually ran a _test_ (you may want to look up what this word might
refer to) by adding the -l MYSUB1 without the -L while having the
LD_LIBRARY_PATH. As I expected it failed, just as Charles reported.

In the bad old days, each flavor of Unix had its own name for the library path searched by
ld and dlopen. AIX used LIBPATH (same as z/OS), HPUX used SHLIB_PATH, OS X used
DYLD_LIBRARY_PATH.

In the late '90s POSIX became the Unix standard. The POSIX name, LD_LIBRARY_PATH, works
on all versions of Unix.

For badkward compatibility, the various Unixen merge their old name with LD_LIBRARY_PATH,
eliminating duplicates, and use the result.

If your test failed, you ran it on an obsolete AIX. Charles reported that LD_LIBRARY_PATH
worked for him.

You are confused yet again.

LD_LIBRARY_PATH is used to load dynamic libraries at run time. When
Charles _ran_ MYMAIN originally (with no -l), it failed to find
libMYSUB1.so until its directory was on the LD_LIBRARY_PATH. I
confirmed this with my tests.

When the -l MYSUB1 was added to the compile it failed to find "-
lMYSUB1" _even_with_ the current directory on the LD_LIBRARY_PATH. My
testing showed this to be the case. Charles added -L . to get ld to
look in the current directory.

I tested this and found exactly that. In a shell script I changed
LD_LIBRARY_PATH to point to the current directory as :.:./: and
explictly with the full path and ld failed to find MYSUB1. Adding -
L . (as Charles did) made it work.

The general rule is that Unix, both ld and dlopen, searches LD_LIBRARY_PATH. If yours
isn't doing that, there is something abnormal in your configuration.

Do you have an ld configuration file? To find out, run crle or look at /etc/ld.so.conf.

Are you using Linux Security? If so, it will only search secure directories in
LD_LIBRARY_PATH. Your home directory is not one of them.

Did you forget to export or setenv LD_LIBRARY_PATH? If so, ld running as a child process
of your script, doesn't see it.

Here's a quote from the ld man page:

"The default set of paths searched (without being specified with -L) depends on which
emulation mode ld is using, and in some cases also on how it was configured."

The linker uses the following search paths to locate required shared libraries:
1.

Any directories specified by -rpath-link options.

2.

Any directories specified by -rpath options. The difference between -rpath and
-rpath-link is that directories specified by -rpath options are included in the executable
and used at runtime, whereas the -rpath-link option is only effective at link time.
Searching -rpath in this way is only supported by native linkers and cross linkers which
have been configured with the --with-sysroot option.

3.

On an ELF system, if the -rpath and "rpath-link" options were not used, search the
contents of the environment variable "LD_RUN_PATH". It is for the native linker only.

4.

On SunOS, if the -rpath option was not used, search any directories specified using -L
options.

5.

For a native linker, the contents of the environment variable "LD_LIBRARY_PATH".

6.

For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" of a shared
library are searched for shared libraries needed by it. The "DT_RPATH" entries are ignored
if "DT_RUNPATH" entries exist.

7.

The default directories, normally /lib and /usr/lib.

8.

For a native linker on an ELF system, if the file /etc/ld.so.conf exists, the list of
directories found in that file.

http://linux.die.net/man/1/ld

Actually, it's more complicated than that. There 4-6 obscure environment variables that
can 'front end' the search path. They are used to 'overload' system libraries.

ls, as I said, does not use LD_LIBRARY_PATH.

It should have. Every Unix machine I've ever worked on did.

And BTW Mandrake is Red Hat based and not on 'an obsolete AIX'.

I suspect you got LIBPATH from this erroneous man page:

If ld is called with any number of occurrences of -L, as
in:

ld ... -Lpath1 ... -Lpathn ...

then the search path ordering is:

dirlist1 path1 ... pathn dirlist2 LIBPATH
http://compute.cnr.berkeley.edu/cgi-bin/man-cgi?ld+1



.

Relevant Pages

  • Re: compile+link Fujitsu Linux
    ... I wasn't trying to change your way of doing things, I was answering Charles' question. ... Charles was unfamiliar with Fujitsu on Unix. ... libraries was 'more secure'. ... YOU introduced application security, not I. ...
    (comp.lang.cobol)
  • Re: compile+link Fujitsu Linux
    ... the Unix and Windows worlds. ... I wasn't trying to change your way of doing things, I was answering Charles' question. ... Security that depends on user ignorance is so 1980s. ... libraries was 'more secure'. ...
    (comp.lang.cobol)
  • Re: [9fans] Standalone unix port of the original rc shell
    ... or whatever the right compiler is -- gcc isn't the only ... Unix has grown ridiculously long-winded in its old age. ... > me is, that all headers reside in $PLAN9/include, which ... libraries they need to be linked with. ...
    (comp.os.plan9)
  • Re: Using the XCode tools on Mac OSX to compile tcl/tk 8.5.5 C application ...
    ... macosx/GNUMakefile or the unix configure & make? ... built dynamic libraries are found... ... and it appears that there is an 8.5 framework now ...
    (comp.lang.tcl)
  • Re: digital image processing... newbie help
    ... >Re-invent is a common negative sound-bite. ... And I was referring to Windows and calling windows... ... >than those writing libraries. ... >same threads about writing C in Forth, writing Unix in Forth, ...
    (comp.lang.forth)