Re: ELF extension for starting symbol search from module dependencies
> Then you have to deal with consistency issues. They do not exist for > self-contained libraries that act locally only like png, but they may > arise with libraries that interact with the outer world, e.g. any that > makes use of networking. For example using different versions of the X11 > library by different parts of a process will certainly lead to surprises. Well, yes, this doesn't work if the conflicting libraries structures are exported by the libraries that use them. In this case the structures become part of the ABI of the intermediary library, so the situation is similar to a program linking directly to two conflicting libraries. However, this often isn't the case. signature.asc Description: This is a digitally signed message part
Re: ELF extension for starting symbol search from module dependencies
On 22 Aug 2002, Luca Barbieri wrote: > > Do you suggest your proposed change should only be activated for the png > > library? > The proposed change is activated for everything that is compiled with > the -Blocal linker option. Then you have to deal with consistency issues. They do not exist for self-contained libraries that act locally only like png, but they may arise with libraries that interact with the outer world, e.g. any that makes use of networking. For example using different versions of the X11 library by different parts of a process will certainly lead to surprises. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+
Re: ELF extension for starting symbol search from module dependencies
On Thu, 2002-08-22 at 21:35, Maciej W. Rozycki wrote: > On 22 Aug 2002, Luca Barbieri wrote: > > > > Hmm, what if two functions which get imported from different versions of > > > the same library operate on a static (private to the library) variable > > > that is needed for a proper operation for some reason? You'd better > > > rebuild the sources to use a single version of each library instead. > > I don't see how this could cause problems. Each png library should bind > > its own references to its own symbols. > > Do you suggest your proposed change should only be activated for the png > library? The proposed change is activated for everything that is compiled with the -Blocal linker option. For the specific case of libpng, the problem can be solved by linking libpng.so.2 and libpng.so.3 with -Bsymbolic and all libraries that use them with -Blocal (alternatively you can also solve this with versioned symbols but this causes more potential compatibility problems). signature.asc Description: This is a digitally signed message part
Re: ELF extension for starting symbol search from module dependencies
On 22 Aug 2002, Luca Barbieri wrote: > > Hmm, what if two functions which get imported from different versions of > > the same library operate on a static (private to the library) variable > > that is needed for a proper operation for some reason? You'd better > > rebuild the sources to use a single version of each library instead. > I don't see how this could cause problems. Each png library should bind > its own references to its own symbols. Do you suggest your proposed change should only be activated for the png library? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+
Re: ELF extension for starting symbol search from module dependencies
On Thu, 2002-08-22 at 11:23, Jakub Jelinek wrote: > On Thu, Aug 22, 2002 at 10:35:33AM +0200, Maciej W. Rozycki wrote: > > On 21 Aug 2002, Luca Barbieri wrote: > > > > > This is a proposal (including patches) for a GNU extension to the ELF > > > executable format that adds a flag that causes the dynamic loader to > > > start searching for symbols referenced by modules with the flag set from > > > the module itself and its immediate dependencies. If the symbol is not > > > found in this way, the dynamic linker continues the search as usual. > > > > > > This extension would be useful to allow to load in the same address > > > space multiple libraries that define identical symbols, that would be > > > used by different modules possibly unaware of each other's use of such > > > symbols. > > > > Hmm, what if two functions which get imported from different versions of > > the same library operate on a static (private to the library) variable > > that is needed for a proper operation for some reason? You'd better > > rebuild the sources to use a single version of each library instead. > > Or, even better, introduce symbol versioning for libpng.so and maintain it > ABI compatible from this point on... Yes, you could compatibly introduce versioning in libraries and continue to build unversioned binaries and it will work. However, this introduces a minor ABI modification that will cause libraries to break if they are used with libraries created by someone else that decided to do the same but invented a different versioning scheme. So this should be done in accordance with the library maintainers and other distributors while this extension can be introduced immediately and used until there is a universally accepted plan to add versioning. Also, libpng is not the only target: this can similarly be used in all the cases where the library maintainers decide to inconvenience everyone else by creating two incompatible libraries with conflicting symbols. BTW, how is RedHat handling this? signature.asc Description: This is a digitally signed message part
Re: ELF extension for starting symbol search from module dependencies
> Hmm, what if two functions which get imported from different versions of > the same library operate on a static (private to the library) variable > that is needed for a proper operation for some reason? You'd better > rebuild the sources to use a single version of each library instead. I don't see how this could cause problems. Each png library should bind its own references to its own symbols. signature.asc Description: This is a digitally signed message part
Re: ELF extension for starting symbol search from module dependencies
On Thu, 2002-08-22 at 08:13, Roland McGrath wrote: > I think you can get the effect you need just by using -Bsymbolic. In your > example, build the GTK+ library with -Bsymbolic. If that causes problems > because some of the library's references should be resolved in the normal > global scope, then confine the code that uses libpng to a wrapper library > that you build with -Bsymbolic. Then link the GTK+ library against that > shared object, and I think you will get the result you need: the GTK+ > library code that uses libpng will be in a DT_SYMBOLIC object and thus > resolve according to its own dependency on the desired libpng soname, > while the application is free to link a conflicting libpng in directly. But -Bsymbolic only puts the module that uses it in front of the search list so the wrapper will use the library used by the program and will fail. You could do this by dlopen'ing libpng and getting symbols from it with dlsym but this requires source modifications and isn't exactly elegant (and lazy lookups require even more modifications). signature.asc Description: This is a digitally signed message part
Re: ELF extension for starting symbol search from module dependencies
On Thu, Aug 22, 2002 at 10:35:33AM +0200, Maciej W. Rozycki wrote: > On 21 Aug 2002, Luca Barbieri wrote: > > > This is a proposal (including patches) for a GNU extension to the ELF > > executable format that adds a flag that causes the dynamic loader to > > start searching for symbols referenced by modules with the flag set from > > the module itself and its immediate dependencies. If the symbol is not > > found in this way, the dynamic linker continues the search as usual. > > > > This extension would be useful to allow to load in the same address > > space multiple libraries that define identical symbols, that would be > > used by different modules possibly unaware of each other's use of such > > symbols. > > Hmm, what if two functions which get imported from different versions of > the same library operate on a static (private to the library) variable > that is needed for a proper operation for some reason? You'd better > rebuild the sources to use a single version of each library instead. Or, even better, introduce symbol versioning for libpng.so and maintain it ABI compatible from this point on... Jakub
Re: ELF extension for starting symbol search from module dependencies
On 21 Aug 2002, Luca Barbieri wrote: > This is a proposal (including patches) for a GNU extension to the ELF > executable format that adds a flag that causes the dynamic loader to > start searching for symbols referenced by modules with the flag set from > the module itself and its immediate dependencies. If the symbol is not > found in this way, the dynamic linker continues the search as usual. > > This extension would be useful to allow to load in the same address > space multiple libraries that define identical symbols, that would be > used by different modules possibly unaware of each other's use of such > symbols. Hmm, what if two functions which get imported from different versions of the same library operate on a static (private to the library) variable that is needed for a proper operation for some reason? You'd better rebuild the sources to use a single version of each library instead. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+
Re: ELF extension for starting symbol search from module dependencies
I think you can get the effect you need just by using -Bsymbolic. In your example, build the GTK+ library with -Bsymbolic. If that causes problems because some of the library's references should be resolved in the normal global scope, then confine the code that uses libpng to a wrapper library that you build with -Bsymbolic. Then link the GTK+ library against that shared object, and I think you will get the result you need: the GTK+ library code that uses libpng will be in a DT_SYMBOLIC object and thus resolve according to its own dependency on the desired libpng soname, while the application is free to link a conflicting libpng in directly.
ELF extension for starting symbol search from module dependencies
This is a proposal (including patches) for a GNU extension to the ELF
executable format that adds a flag that causes the dynamic loader to
start searching for symbols referenced by modules with the flag set from
the module itself and its immediate dependencies. If the symbol is not
found in this way, the dynamic linker continues the search as usual.
This extension would be useful to allow to load in the same address
space multiple libraries that define identical symbols, that would be
used by different modules possibly unaware of each other's use of such
symbols.
As a practical example, libpng.so.2 and libpng.so.3 define several
symbols with identical names.
With the current ELF format, other libraries that want to use libpng
symbols will use the symbols of the libpng library that is used by the
main program rather than the one they are compiled with.
Since GTK+ 2.0 uses libpng, this causes a major problem since GTK+
application must be recompiled to use the same libpng version that GTK+
uses.
With this extension, GTK+ could be recompiled with the new flag set and
this problem would be solved.
The extension is implemented using bit 0 of the value attached to the
DT_SYMBOLIC dynamic section entry. Current versions of the GNU dynamic
loader ignore this value and thus consider the object like one compiled
with the -Bsymbolic option.
An option is added to the GNU linker to allow it to produce executables
with the flag set. The proposed name for the option is -Blocal.
This option is treated like -Bsymbolic, but will cause the value
attached to the DT_SYMBOLIC entry to be written as 1 rather than 0.
The attached patches implement the two modifications. The libc patch
also changes the -Bsymbolic list to be statically allocated rather than
malloc'ed and leaked.
Patch for GNU binutils:
--- a/bfd/elflink.h 2002-07-17 20:38:29.0 +0200
+++ b/bfd/elflink.h 2002-08-21 15:27:17.0 +0200
@@ -3042,7 +3042,7 @@ NAME(bfd_elf,size_dynamic_sections) (out
if (info->symbolic)
{
if (! elf_add_dynamic_entry (info, (bfd_vma) DT_SYMBOLIC,
- (bfd_vma) 0))
+ (bfd_vma) (info->local ? 1 : 0)))
return false;
info->flags |= DF_SYMBOLIC;
}
--- a/include/bfdlink.h 2002-07-17 20:38:29.0 +0200
+++ b/include/bfdlink.h 2002-08-21 15:27:58.0 +0200
@@ -216,6 +216,10 @@ struct bfd_link_info
/* true if BFD should pre-bind symbols in a shared object. */
boolean symbolic;
+ /* true if BFD should pre-bind symbols in a shared object and tell
+ dynamic linker to start searching from local dependencies. */
+ boolean local;
+
/* true if BFD should export all symbols in the dynamic symbol table
of an executable, rather than only those used. */
boolean export_dynamic;
--- a/ld/ldmain.c 2002-07-17 20:38:29.0 +0200
+++ b/ld/ldmain.c 2002-08-21 15:27:08.0 +0200
@@ -234,6 +234,7 @@ main (argc, argv)
link_info.emitrelocations = false;
link_info.shared = false;
link_info.symbolic = false;
+ link_info.local = false;
link_info.export_dynamic = false;
link_info.static_link = false;
link_info.traditional_format = false;
--- a/ld/lexsup.c 2002-05-24 00:10:11.0 +0200
+++ b/ld/lexsup.c 2002-08-21 15:26:52.0 +0200
@@ -133,6 +133,7 @@ int parsing_defsym = 0;
#define OPTION_NO_DEFINE_COMMON(OPTION_SPARE_DYNAMIC_TAGS + 1)
#define OPTION_NOSTDLIB(OPTION_NO_DEFINE_COMMON + 1)
#define OPTION_MULTILIB_DIR(OPTION_NOSTDLIB + 1)
+#define OPTION_LOCAL (OPTION_MULTILIB_DIR + 1)
/* The long options. This structure is used for both the option
parsing and the help text. */
@@ -283,6 +284,8 @@ static const struct ld_option ld_options
'\0', NULL, NULL, ONE_DASH },
{ {"Bsymbolic", no_argument, NULL, OPTION_SYMBOLIC},
'\0', NULL, N_("Bind global references locally"), ONE_DASH },
+ { {"Blocal", no_argument, NULL, OPTION_LOCAL},
+ '\0', NULL, N_("Bind global references locally and start searching from
local dependencies"), ONE_DASH },
{ {"check-sections", no_argument, NULL, OPTION_CHECK_SECTIONS},
'\0', NULL, N_("Check section addresses for overlaps (default)"),
TWO_DASHES },
{ {"no-check-sections", no_argument, NULL, OPTION_NO_CHECK_SECTIONS},
@@ -924,6 +927,10 @@ parse_args (argc, argv)
case OPTION_SYMBOLIC:
link_info.symbolic = true;
break;
+ case OPTION_LOCAL:
+ link_info.symbolic = true;
+ link_info.local = true;
+ break;
case 't':
trace_files = true;
break;
Patch for GNU libc:
--- a/elf/dl-deps.c 2001-09-21 16:52:54.0 +0200
+++ b/elf/dl-deps.c 2002-08-21 14:55:17.0 +0200
@@ -261,7 +261,8 @@ _dl_map_object_deps (struct link_map *ma
