> I am somewhat unfamilar with what the XFORM doumentation refers to as
> LD_LIBRARY_PATH ....
> Whould you use set to set the value (allready tried and failed), or
> what?
This points, at run time, to where the shared libraries live if
they're installed in some non-standard place that the system doesn't
already know about. Some linker/loaders will store this information
in the executable so that `ld.so' or its equivalent will have it when
the application is started. Other linker/loaders, such as SGI's,
require you to explicitly specify a path, either a link time with
linker directives, or a run time with LD_LIBRARY_PATH.
To specify LD_LIBRARY_PATH, invoke the command
setenv LD_LIBRARY_PATH /wherever/your/shared/libraries/live
For instance, if you have put your XForms shared libraries in
`/usr/local/imports/lib', you'd type
setenv LD_LIBRARY_PATH /usr/local/imports/lib
and then run your application.
You can put this in your .cshrc, .login, or equivalent for your
favorite shell.
The alternative, as I mention, is to tell the loader explicitly to
store this information. On an SGI it would look like
gcc -o my_app -Xlinker -rpath -Xlinker /usr/local/imports/lib ...
Then when run `my_app' I don't have to do anything special -- `ld.so'
finds it automagically.
Your linker/loader may want something different.
Finally, the easiest thing to do may be to link statically. Although
it makes for a bigger binary, to be sure, you're at least assured that
you will not have problems with libraries being moved and having to
deal with extraneous `setenv' operations.
Consult the manual pages for `ld' and `ld.so' for various details.
spl
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
Xforms Home Page: http://bloch.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/