Board index Unix Questions

ld.so not finding fortran shared libraries

ld.so not finding fortran shared libraries

Post by Nick J. Re » Thu, 29 Apr 1993 07:31:35



I have a program written mainly in C but with a fortran main
module. The program uses set-user-ID. I have /user/lang/SC0.0
in the environment variable LD_LIBRARY_PATH ( which is where
the libF77.so.* files exist. )

On a local SPARC runninig SunOS 4.1.2 I link the program without
specifying the fortran library locations explicitly with the -L
flag. I set the sticky bit and give world read and execute
privileges. Now the owner and anyone else can execute it.

Now I distribute the executable to a remote Solbourne running
OS/MP 4.1A (?). I set the privileges as before and now the owner
can run it but gets the warning:

ld.so: warning: /usr/lang/SC0.0/libF77.so.1.1 has older revision
than expected 4
ld.so: warning: /usr/lib/libc.so.1.6 has older revision than
expected 7

Anybody else ( with LD_LIBRARY_PATH set the same as for the owner )
gets:

ld.so: libF77.so.1: not found

Now I see from the man pages for ld.so that as a security precaution
ld.so will not search LD_LIBRARY_PATH for a set-user-ID program.
I am now puzzled as to why it works on the original system.

I tried running the strings utility on the image and I don't see
any references to /usr/lang/SC0.0. I don't see any links in the
"trusted" directories to to the libF77.so.1.1 file and the
/usr/lang/SC0.0 directory was not specified as a -L option on the
original link.

Can somebody please explain what is happening.
Thanks.
--
 ===============================Nick Rees===============================

  mail: Texaco, Inc., 3901 Briarpark, Houston, TX 77042
========================================================================

 
 
 
Top

ld.so not finding fortran shared libraries

Post by Barry Margol » Fri, 30 Apr 1993 02:13:35



Quote:>On a local SPARC runninig SunOS 4.1.2 I link the program without
...
>Now I distribute the executable to a remote Solbourne running
>OS/MP 4.1A (?). I set the privileges as before and now the owner
>can run it but gets the warning:

>ld.so: warning: /usr/lang/SC0.0/libF77.so.1.1 has older revision
>than expected 4
>ld.so: warning: /usr/lib/libc.so.1.6 has older revision than
>expected 7

These warnings are because the Solbourne has older versions of these
libraries than the Sun.  I think OS/MP 4.1A is based on SunOS 4.1.1.  In
general, you should compile and link a program on the oldest OS release you
plan to run on; it gets rid of these warnings and avoids compatibility
problems.

Quote:>Now I see from the man pages for ld.so that as a security precaution
>ld.so will not search LD_LIBRARY_PATH for a set-user-ID program.
>I am now puzzled as to why it works on the original system.
>I tried running the strings utility on the image and I don't see
>any references to /usr/lang/SC0.0. I don't see any links in the
>"trusted" directories to to the libF77.so.1.1 file and the

It says it expected revision 4; did you look for a link to libF77.so.1.4?
Actually, you should look for anything named libF77.so.1.* in the trusted
directories, since it will link without complaint to the version with the
highest minor revision.
--
Barry Margolin
System Manager, Thinking Machines Corp.



 
 
 
Top

1. ld shared library linking -- symbol not found: fstat

I'm working on porting a set of libraries that currently run on several other
un*x systems to Linux.  Our makefiles use ld in order to do the final linking
of objects into the shared libraries.  Essentially, the ld command we use for
the final link is this:

  /usr/bin/ld -shared -o libmylib.so obj1.o obj2.o obj3.o -ldl

Unfortunately, when we try to run an application linked against this libarary,
we get the following error:

  testapp: error while loading shared libraries: libmylib.so: undefined symbol:
  fstat

This is on a Red Hat 7.2 system using the "stock" compiler, linker, etc.

Now I know that this can be solved by adding -lc to the ld command to link
against libc, but I was wondering if there is some other ld flag I could use so
that this wouldn't be necessary.

Also, I have another question.  Earlier we had some an experimental port of
this library to Red Hat 6.x (I forget the exact version, I think it was 6.2,
but I'm not sure), and as far as I know (I didn't do the port) everything
worked without ld explicitly linking with libc on its command line.  Did
something change in the linker between these two versions of Red Hat or
something?

Thanks!

--

-------------------- http://www.techhouse.org/lou ----------------------
"Dragonmaster Lou"    | "Searching for a distant star, heading off to  
lou at techhouse org  | Iscandar, leaving all we love behind, who knows
Tech House Alum       | what dangers we'll find..."                    
-----------------------------------------------------------------------

2. Unable to determine Adaptec DMA piority.... ??

3. FORTRAN common in AIX shared library not shared at runtime (0/1)

4. Setting up X-Windows

5. Perl5 error: ld.so failed: Can't find shared library "libnet.so.0.92"

6. How to limit cpu time per process per user account

7. ld.so failed: Can't find shared library "libXmu.so.6.0"

8. module_init

9. Netscape Navigator - ld.so failed: Can't find shared library "libXt.so.6.0"

10. help with ld script to build iBCS shared library (gnu ld 2.2)

11. When is a shared library not a shared library?

12. ld: fatal: library -lxxx: not found

13. ld does not find a library


All times are UTC
Board index