Free Downloads, Community Forum,
FAQs and Developer Resources


Make /Tools Your Home | Link to us

Today's posts | Posts since last visit | Most Active Topics

All Forums Register Login Search Subscriptions My Profile Inbox
Tool Warehouse FAQs Resources Help Member List Address Book Logout

libdl.so.3.5

 
Logged in as: Guest
Users viewing this topic: none
  Printable Version
All Forums >> [SFU / Interix / SUA Technology] >> Windows Server 2003 R2 SUA >> libdl.so.3.5 Page: [1]
Login
Message << Older Topic   Newer Topic >>
libdl.so.3.5 - Jun. 1, '06, 5:07:47 AM   
rapid

 

Posts: 8
Joined: Jun. 1, '06,
Status: offline
We have an program compiled with gcc under Windows XP with SFU 3.5 that issues dlopen().

objdump /p shows libdl.so.3.5 is NEEDED. libdl.so.3.5 is not in our makefile. I suspect that gcc or ld has figured out that libdl.so = libdl.so.3.5.

On Windows 2003 R2 with SUA, the program fails in the dlopen() with a SEGV.

In Windows 2003 R2 /usr/lib, libdl.so and libdl.so.5.2 are soft links to /opt/gcc.3.3/lib/libdl.so.5.2. There is a copy of libdl.so.3.5 in /usr/lib.

If I remove /usr/lib/libdl.so.3.5 and create a soft link /usr/lib/libdl.so.3.5 to /usr/lib/libdl.so.5.2 the dlopen() succeeds and the program works OK.

So: libdl.so.5.2 is OK, libdl.so.3.5 is NBG. If the program had a dependency on libdl.so, it would work on 5.2 SUA without change.

My questions:

1) Why does gcc or ld create a dependency on libdl.so.3.5 rather than libdl.so ? This seems to negate one of the objectives of dynamic linking.

2) Do you know of a gcc or ld option which will create a dependency on libdl.so rather than libdl.so.3.5 ?

Many thanks for this excellent forum which has helped us on many issues.

Rapid
Post #: 1
RE: libdl.so.3.5 - Jun. 1, '06, 8:00:41 AM   
Rodney

 

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
From OS version to OS version the shared lib numbering allows for updates, even
"break the world" updates, without adversely affecting existing/pre-existing binaries.
Usually there is the slight-of-hand with symbolic links for shared libraries since
several versions will point to the same end library. The "generic" libFOO.so is one
of these. It'll point to an actual version numbered shared library. The linker will
take this as "_the_" version. It's a gamble to do otherwise (this isn't an Interix
thing BTW).

When Interix 5.2 initially shipped the shared library support was hosed for 3.5 binaries.
Up to 5.2/RC1 things had been fine, but by 5.2/RTM something derailed.
When the updated install of the utilities and libraries shipped Jan/6/2006 this was fixed for libc and libdl.
But I wasn't aware of specific problem with shared libraries after this.
Do you have the 6/Jan install?

> Many thanks for this excellent forum which has helped us on many issues.

You're welcome

(in reply to rapid)
Post #: 2
RE: libdl.so.3.5 - Jun. 2, '06, 10:12:01 AM   
rapid

 

Posts: 8
Joined: Jun. 1, '06,
Status: offline
The date of the Microsoft digital signature of the SUA download is 07 January 2006 11:45:08.

The file name is Utilities and SDK for UNIX-based Applications_X86

(in reply to Rodney)
Post #: 3
RE: libdl.so.3.5 - Jun. 5, '06, 11:37:41 AM   
Rodney

 

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
That download date is the most current for 5.2 WRT the *.so's.

You can do the workaround you have now, or try to get a fix through MS support.

(in reply to rapid)
Post #: 4
Page:   [1]
All Forums >> [SFU / Interix / SUA Technology] >> Windows Server 2003 R2 SUA >> libdl.so.3.5 Page: [1]
Jump to:





New Messages No New Messages
Hot Topic w/ New Messages Hot Topic w/o New Messages
Locked w/ New Messages Locked w/o New Messages
 Post New Thread
 Reply to Message
 Post New Poll
 Submit Vote
 Delete My Own Post
 Delete My Own Thread
 Rate Posts


Search All Forums -

Advanced search


SPONSORS



Forum Software © ASPPlayground.NET Advanced Edition 2.5 ANSI

0.031