On Wed, 23 Mar 2005 19:52:00 +0000 (UTC), Rui Paulo
<rpaulo@netbsd-pt.org> wrote:
> When building packages, pkgsrc adds linker flags to gcc command line,
> so, when the program is executed, some library paths are hardcoded in
> ELF's .dynamic section:

I've been trying to create a package for omniORB. I'm to the point of
testing out the libraries, so I built the demo found in the
documentation. The link line for the demo is:

    g++ -g -R /usr/pkg/lib -L /usr/pkg/lib -o eg1 echoSK.o eg1.o \
        -lomniORB4 -lomnithread -lpthread

When I run the test app, I get:

    Shared object "libomnithread.so.3" not found

Using your "objdump" example (partially) shows:

    Dynamic Section:
      NEEDED      libomnithread.so.3
      NEEDED      libomniORB4.so.0
      NEEDED      libpthread.so.0
      NEEDED      libstdc++.so.5
      NEEDED      libm.so.0
      NEEDED      libgcc_s.so.1
      NEEDED      libc.so.12
      RPATH       /usr/pkg/lib

Yet, omnithread did get installed:

$ ls -l /usr/pkg/lib/libomnithread*
-rw-r--r--  1 root  wheel    22208 Mar 22 21:35 /usr/pkg/lib/libomnithread.a
lrwxr-xr-x  1 root  wheel       18 Mar 22 21:35
/usr/pkg/lib/libomnithread.so -> libomnithread.so.3
lrwxr-xr-x  1 root  wheel       20 Mar 22 21:35
/usr/pkg/lib/libomnithread.so.3 -> libomnithread.so.3.0
-rwxr-xr-x  1 root  wheel    27699 Mar 22 21:35
/usr/pkg/lib/libomnithread.so.3.0

Rereading this thread, I was reminded of the 'ldd' command. Running it
exposed this:

$ ldd eg1
eg1:
         -lomnithread.3 => not found
         -lpthread.0 => /usr/lib/libpthread.so.0
         -lstdc++.5 => /usr/lib/libstdc++.so.5
         -lm.0 => /usr/lib/libm387.so.0
         -lm.0 => /usr/lib/libm.so.0
         -lgcc_s.1 => /usr/lib/libgcc_s.so.1
         -lomniORB4.0 => /usr/pkg/lib/libomniORB4.so.0
         -lc.12 => /usr/lib/libc.so.12
         -lomnithread.3 => /usr/pkg/lib/libomnithread.so.3

omnithread is in the list twice! The first entry is "not found", so it
fails to load the executable. Maybe there's a dependency in the
omniORB4 library to the omnithread library... When I built the
package, the runtime path wasn't properly specified?

Anyone have any ideas?

Getting back to Mr. Pereira's original posting... does the wmswallow
project have several libraries that are dependant on each other?

--
Rich

AIM : rnezzy
ICQ : 174908475