search for: dt_need

...ommand line, it certainly should know about the input > graph. I wouldn't be surprised if it can make a significant difference > for group processing whether a DFS or BFS is applied, even if the result > doesn't change. There are other concerns like the recursive processing > of DT_NEEDED for ELF and the resulting implications for symbol > resolution and locking. Someone should certainly know about the input graph, but it isn't necessarily be Resolver. In my proposal Linking Context gets update for each step of linking from Resolver and makes a decision based on that. I d...

...ared definition to an undefined symbol here: https://github.com/llvm/llvm-project/blob/c8bfed05e21f945b5ac71cd01d62e2854a8ddcf9/lld/ELF/Driver.cpp#L1505 I'm guessing the fix is that if `needsInterpSection()` is true then the dynamic linker should be marked as needed. Its going to end up in the DT_NEEDED anyway so the symbols can't become dangling references. In my case then, the demotion won't happen and everything works as expected. Is this the right direction? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/at...

On Fri, Sep 20, 2013 at 05:29:32PM -0700, Rui Ueyama wrote: > I don't also understand if DT_NEEDED is related to this. DT_NEEDED is not > represented by input graph. And what is *recursive* processing of DT_NEEDED? Searching a symbol in a shared library according to ELF semantics means recursively searching in all depending libraries as well. Joerg

...the details of the command line, it certainly should know about the input graph. I wouldn't be surprised if it can make a significant difference for group processing whether a DFS or BFS is applied, even if the result doesn't change. There are other concerns like the recursive processing of DT_NEEDED for ELF and the resulting implications for symbol resolution and locking. Joerg

...4): undefined reference to `fn1' Any ways of making the GNU linker do a DFS/BFS search on dependent libraries ? Thanks Shankar Easwaran On 9/21/2013 5:25 AM, Joerg Sonnenberger wrote: > On Fri, Sep 20, 2013 at 05:29:32PM -0700, Rui Ueyama wrote: >> I don't also understand if DT_NEEDED is related to this. DT_NEEDED is not >> represented by input graph. And what is *recursive* processing of DT_NEEDED? > Searching a symbol in a shared library according to ELF semantics means > recursively searching in all depending libraries as well. > > Joerg > _____________...

...the purposes of satisfying -z > defs? The executable will always be searched first, so the interface DSO > could be empty or full of ud2a. I like the idea. The ideal solution would probably be for the linkers to have a --not-needed command line option that prevents the .so from going in the DT_NEEDED, but one with just stubs is probably fine. Cheers, Rafael

On Fri, Sep 20, 2013 at 3:59 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Sep 20, 2013, at 3:37 PM, Rui Ueyama <ruiu at google.com> wrote: > > On Fri, Sep 20, 2013 at 3:29 PM, Nick Kledzik <kledzik at apple.com> wrote: > >> Rui, >> >> I like this in general, but have a few questions. >> >> On Sep 20, 2013, at 2:30 PM, Rui

...clear, the situation is: > > > > nbdkit (free) > > -> dlopens nbdkit-vddk-plugin.so (free) > > -> dlopens libvixDiskLib.so (proprietary) > > -> dlopens other proprietary plugins > > -> both libvixDiskLib.so and its plugins have DT_NEEDED > > "libstdc++.so.X" and other objects that have odd/old > > compiled versions in its own directory > > > > It's the proprietary library libvixDiskLib.so (colloquially known as "VDDK") > > which has trouble opening its own...

...d when building with msan because of undefined references to functions like __msan_memcpy. Unfortunately, I don't think elf linkers have a way of informing them that a given symbol will be provided at runtime. It is possible to pass a dummy executable build with msan, but that gets recorded in DT_NEEDED. My understanding is that the msan library provides two things: an initialization code that has to run really early and auxiliary functions like __msan_memcpy. Would it be possible to split libclang_rt.msan-x86_64.a such that the utility functions are available on a .so (or at least a -fPIC .a)...

...kit to quit messing with argv[] so that /proc/self/cmdline would stay stable - but that did not require a new API). 2. it turns out that overriding dlopen() was insufficient to work around VDDK's setup [2]. It _did_ solve the initial dlopen() performed by VDDK, but that library in turn had DT_NEEDED entries for bare library names, which dlopen() does NOT affect but which la_objsearch() should. 3. for nbdkit, we want to minimize the number of binary files shipped; the re-exec solution works with just the nbdkit binary and the nbdkit-vddk-plugin.so. Any solution that requires a third file...

On Fri, Feb 21, 2020 at 01:19:34PM +0100, Florian Weimer wrote: > I think what confuses me is that keep talking about a single binary, but > clearly there is this separate vddk DSO, and there is talk of plugins. > So it seems to me that multiple files are involved already? nbdkit is a standalone binary that happens to be able to load plugins from a well-known path, eg

...irst place. On Mon, Dec 19, 2016 at 2:27 PM, Mark Kettenis via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On OpenBSD we still use the "classic" SunOS 4 shared library > versioning scheme where the major and minor number are part of the > library name (and recorded in DT_NEEDED entries). For example the > shared libc on the OpenBSD-current is named libc.so.89.2. With this > scheme, linker has to pick the pick the library with the highest major > and minor (within the highest major version); the symbolic links > present on most other ELF-based systems don...

...or: nbdkit: debug: VixDiskLib: Could not load default plugins from /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64/libdiskLibPlugin.so: Cannot open library: libcrypto.so.1.0.2: cannot open shared object file: No such file or directory. So I guess libcrypto is actually loaded from a DT_NEEDED entry: $ eu-readelf -d /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64/libdiskLibPlugin.so | grep NEEDED NEEDED Shared library: [libpthread.so.0] NEEDED Shared library: [libstdc++.so.6] NEEDED Shared library: [libdl.so.2] NEEDED...

...gt; Or does the path have to be chosen dynamically? To be clear, the situation is: nbdkit (free) -> dlopens nbdkit-vddk-plugin.so (free) -> dlopens libvixDiskLib.so (proprietary) -> dlopens other proprietary plugins -> both libvixDiskLib.so and its plugins have DT_NEEDED "libstdc++.so.X" and other objects that have odd/old compiled versions in its own directory It's the proprietary library libvixDiskLib.so (colloquially known as "VDDK") which has trouble opening its own plugins. I guess you mean adding DT_* to the pro...

On Fri, 2012-06-29 at 07:42 -0700, syslinux-bot for H. Peter Anvin wrote: > elflink: fix dependency problem in cmenu/Makefile > > Instead of adding library dependencies implicitly, make them explicit > and use --as-needed to avoid bogus DT_NEEDED entries from being > generated. This is fine, but... > diff --git a/com32/cmenu/Makefile b/com32/cmenu/Makefile > index 40a09d1..c6e0cae 100644 > --- a/com32/cmenu/Makefile > +++ b/com32/cmenu/Makefile > @@ -17,26 +17,15 @@ > > NOGPL := 1 > > -# This must be d...

...a a list of tag and value pairs. These entries are interpreted (and potentially validated) before being written to the .dynamic section. The simplest way to satisfy this requirement is for all dynamic entry values to be numeric values. Unfortunately, this inherently prevents entries like DT_SONAME, DT_NEEDED, DT_RPATH, and DT_RUNPATH from being specified alongside dynamic symbols due to the design of yaml2obj. This proposal introduces three ways to input a value for a dynamic entry. For a given dynamic tag, one or more of these methods of setting a value may be permitted. All of these cases are ill...

...kit: debug: VixDiskLib: Could not load default plugins from /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64/libdiskLibPlugin.so: Cannot open library: libcrypto.so.1.0.2: cannot open shared object file: No such file or directory. > > So I guess libcrypto is actually loaded from a DT_NEEDED entry: ...but that's indeed frustrating. > > $ eu-readelf -d /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64/libdiskLibPlugin.so | grep NEEDED > NEEDED Shared library: [libpthread.so.0] > NEEDED Shared library: [libstdc++.so.6] &...

On OpenBSD we still use the "classic" SunOS 4 shared library versioning scheme where the major and minor number are part of the library name (and recorded in DT_NEEDED entries). For example the shared libc on the OpenBSD-current is named libc.so.89.2. With this scheme, linker has to pick the pick the library with the highest major and minor (within the highest major version); the symbolic links present on most other ELF-based systems don't exist on OpenBS...

...control their link order explicitly via the command line. In my ideal world, archive libraries would carry dependency information rather than the individual objects within them. I suspect that's too much to ask. I see no need for shared libraries to carry any dependency information beyond the DT_NEEDED entries they already have. (It would be so much easier to build a self-driving car if we could immediately jump to the point where all cars are self-driving, right?) -cary

I'm not seeing how to set this path option? Here is what I get using vesamenu.c32 as an example when moved to a directory outside of the build. The current syslinux 4.06 has all the files in the same directory which is at the root of the cd. ldd vesamenu.c32 linux-gate.so.1 => (0xb77c5000) ../../com32/libutil/libutil_com.c32 => not found ../../com32/lib/libcom32.c32 => not found