Re: Need a little help with a dynamic linking problem
Sorry for my late reply... I was tied up on other projects. A few days ago, in a galaxy not far away... In message 20120426080649.go2...@deviant.kiev.zoral.com.ua, Konstantin Belousov kostik...@gmail.com wrote: You need to pass --export-dynamic to the linker when linking binary that is supposed to export its own symbols. Yes! Thank you Konstantin. Using that linker option... or more accurately it's gcc equivalent (-rdynamic) did indeed clear up the problem I was having with gthumb's (dynamic plug-in?) extension modules not seeing the symbols in the main exectuable. I'm not at all sure why this option wasn't already integrated into the relevant Makefiles (for gthumb). I will be looking into that further. Regards, rfg P.S. If it were me, I think I would have implemented that linker option the other way around, i.e. made the default that symbols in the main executable _are_ externally visible by default, and then I would have provided an option to make them non-visible, when and if that is/was ever useful. Sigh. Oh well. I wasn't there at the time. It's just water under the bridge now. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Need a little help with a dynamic linking problem
On Wed, Apr 25, 2012 at 05:58:37PM -0700, Ronald F. Guilmette wrote: In message CADt0fhw=cOrwaAmb8VNDRbCnwAuzhRyu=n3l_so732epv1v...@mail.gmail.com , you wrote: Without being able to look at the details in-depth myself, it looks like the shared object is looking for a symbol which the RTLD can't resolve. That much seems self-evident. The error message itself in effect says precisely that. The symbol is defined in the gthumb application itself. Is that symbol exported such that shared objects can reference it? Based on the outcome, I would have to say that this answer to that question is also (self-evidently?) no. But I'm really not sure, frankly, because I have never before seen an instance of anybody trying to do something screwy like this... I mean having a shared library that depends upon somthing (a symbol) that is intended to be satisfied by the main executable. Frankly, this seems altogether screwy and bizzare to me. Unsually, the main executable depends on (or uses, dynamically) a number of shared libraries. Sharded libraries in turn typically depend on either (a) nothing at all or else (b) some combination of other shared and/or static linking libraries. That has always been my own past experience anyway. By like I said, I have been away from the software development tools for awhile, so mabe having a dynamic library that depends upon something in the main executable is considered kosher now. (Or maybe it ain't, actually, but it is nonthelwess one of those screwy things that the current or original developer or maintainer found out that he could get away with anyway, you know, like JUST over on that well-known hobbist OS whose name begins with the letter L.) Like I say. I don't know, cuz I'm not the developer/maintainer of this thing. If the problem is still unresolved by tomorrow... It doesn't seem to be healing on its own so far... I can draft up a sample and confirm my suspicions (that non-exported symbols won't be resolvable by dynamically-loaded shared objects). Oh, I do believe that you are 100% correct about that. This much, at least, I _do_ remember from ancient times when I worked on the GNU software develop- ment tools (including the linker). In every object file... either a main executable or a shared library, there are symbols that are externally available/visible and then there are ones that aren't... i.e. that are local, and that the dynamic linker either never sees or, at any rate, doesn't pay any attention to. But my dim recollection is that you can easily tell which is which by looking at the type letter that appears next to the symbol in the `nm' output. For example: % nm gthumb | fgrep gth_viewer_page_get_type 004aaf10 T gth_viewer_page_get_type ^ Here, the symbol type indicator is the letter `T', meaning that this is a ``text'' (executable/code) type of symbol. That much I know for sure. The part I am less clear about anymore is that I _think_ I remember that when the type letter on the nm output is a capital letter (as in this case) it means that the symbol in question is ``public'' and available for linking. (Actually, I _am_ pretty darn sure that this is indeed what CAPITAL type letters in the nm output mean.) The only other thing that I can't quite remember anymore is whether such a symbol is always and necessarily available for *dynamic* linking purposes. It might perhaps just be externally available visible ONLY for *static* linking purposes, in which case that might explain why I am seeing a `T' on the nm output for the required symbol, but yet the dynamic linker clearly can't seem to find it. You need to pass --export-dynamic to the linker when linking binary that is supposed to export its own symbols. pgpo71aLSij2q.pgp Description: PGP signature
Need a little help with a dynamic linking problem
My question relates to a port that I am doing of gthumb v2.14.3 to FreeBSD. Because gthumb is fundamentally a gnome application, I am cross-posting my question to both the ports and gnome mailing lists. (My apologies if that means that some of you see this twice.) After a modest but unexpected amount of gnashing of teeth and tearing of hair, I have been able to get gthumb 2.14.3 built and installed on my FreeBSD 8.2 system. Now comes to the fun part... I have installed the whole thing under a special (temporary) directory that I created called /usr/local/hacked. When I try to run the gthumb binary that I built and install, I am getting the following perplexing error message: /libexec/ld-elf.so.1: /usr/local/hacked/lib/gthumb/extensions/libfile_viewer.so: Undefined symbol gth_viewer_page_get_type Quite obviously, I have been away from working on the GNU software development toolchain (and its friends, like ld-elf.so) for far far too long, because I no longer even know how this stuff is even supposed to work, i.e. when it is (knock on wood) working correctly. So if someone who knows this stuff can take pity on me and pass me a clue about what I need to do to resolve the above dynamic linking failure, I sure would appreciate it. Some relevant background: The main gthumb binary is installed in /usr/local/hacked/bin/gthumb and that's what I am running when I run it. It seems pretty obviously to me that the main gthumb executable, when executed, is then trying to dynamically pull in various of the *.so shared library files that got installed into /usr/local/hacked/lib/gthumb/extensions directory as part of the nominal build+install process for gthumb. One last important point: I've checked, and the symbol gth_viewer_page_get_type _is_ in fact defined. It is defined within the main gthumb executable itself: % nm gthumb | fgrep gth_viewer_page_get_type 004aaf10 T gth_viewer_page_get_type So, um, sombody please pass me a clue... How come the dynamic linker doesn't seem to know that the symbol it is looking for was and is defined in the main executable file that the present process originated with? (This specific lack of cognition on the part of the dynamic linker seems to me to be rather reminicent of Alzheimer's.) Regards, rfg P.S. I have already tried both of the following commands prior to executing my gthumb executable and neither of these made a bit of difference to the outcome. I still got the exact same dynamic linker (fatal) error in both cases... setenv LD_LIBRARY_PATH /usr/local/hacked/bin setenv LD_LIBRARY_PATH /usr/local/hacked/lib/gthumb/extensions ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Need a little help with a dynamic linking problem
In message 450d1c59-c403-463b-9c35-6af26f63d...@mac.com, you wrote: On Apr 25, 2012, at 5:01 PM, Ronald F. Guilmette wrote: When I try to run the gthumb binary that I built and install, I am getting the following perplexing error message: /libexec/ld-elf.so.1: /usr/local/hacked/lib/gthumb/extensions/libfile_viewer .so: Undefined symbol gth_viewer_page_get_type Does running ldconfig /usr/local/hacked/lib help? Not here it doesn't... root# ldconfig /usr/local/hacked/lib ldconfig: /usr/local/hacked/lib: ignoring directory not owned by root But anyway, why would it? The ``missing'' symbol is defined in the file /usr/local/hacked/bin/gthumb, as I said. ^^^ What does ldd say about things? Which things? % ldd /usr/local/hacked/lib/gthumb/extensions/libfile_viewer.so: /usr/local/hacked/lib/gthumb/extensions/libfile_viewer.so: libm.so.5 = /lib/libm.so.5 (0x800c0) libc.so.7 = /lib/libc.so.7 (0x800647000) % ldd /usr/local/hacked/bin/gthumb /usr/local/hacked/bin/gthumb: libclutter-gtk-0.10.so.0 = /usr/local/lib/libclutter-gtk-0.10.so.0 (0x800718000) libclutter-glx-1.0.so.0 = /usr/local/lib/libclutter-glx-1.0.so.0 (0x800823000) libSM.so.6 = /usr/local/lib/libSM.so.6 (0x800a71000) libICE.so.6 = /usr/local/lib/libICE.so.6 (0x800b79000) libgtk-x11-2.0.so.0 = /usr/local/lib/libgtk-x11-2.0.so.0 (0x800c93000) libgdk-x11-2.0.so.0 = /usr/local/lib/libgdk-x11-2.0.so.0 (0x8011ac000) libatk-1.0.so.0 = /usr/local/lib/libatk-1.0.so.0 (0x80135f000) libpangocairo-1.0.so.0 = /usr/local/lib/libpangocairo-1.0.so.0 (0x80148) libgdk_pixbuf-2.0.so.0 = /usr/local/lib/libgdk_pixbuf-2.0.so.0 (0x80158d000) libcairo.so.2 = /usr/local/lib/libcairo.so.2 (0x8016ab000) libpng.so.6 = /usr/local/lib/libpng.so.6 (0x801863000) libpango-1.0.so.0 = /usr/local/lib/libpango-1.0.so.0 (0x80198d000) libgconf-2.so.4 = /usr/local/lib/libgconf-2.so.4 (0x801ad6000) libgio-2.0.so.0 = /usr/local/lib/libgio-2.0.so.0 (0x801c12000) libz.so.5 = /lib/libz.so.5 (0x801e36000) libgmodule-2.0.so.0 = /usr/local/lib/libgmodule-2.0.so.0 (0x801f4b000) libgobject-2.0.so.0 = /usr/local/lib/libgobject-2.0.so.0 (0x80204e000) libgthread-2.0.so.0 = /usr/local/lib/libgthread-2.0.so.0 (0x80219a000) libglib-2.0.so.0 = /usr/local/lib/libglib-2.0.so.0 (0x80229e000) libintl.so.9 = /usr/local/lib/libintl.so.9 (0x802488000) libm.so.5 = /lib/libm.so.5 (0x802591000) libthr.so.3 = /lib/libthr.so.3 (0x8026b1000) libc.so.7 = /lib/libc.so.7 (0x8027ca000) libGL.so.1 = /usr/local/lib/libGL.so.1 (0x802a0c000) libdrm.so.2 = /usr/local/lib/libdrm.so.2 (0x802b94000) libjson-glib-1.0.so.0 = /usr/local/lib/libjson-glib-1.0.so.0 (0x802c9e000) libXinerama.so.1 = /usr/local/lib/libXinerama.so.1 (0x802dbb000) libXi.so.6 = /usr/local/lib/libXi.so.6 (0x802ebd000) libXrandr.so.2 = /usr/local/lib/libXrandr.so.2 (0x802fcc000) libXext.so.6 = /usr/local/lib/libXext.so.6 (0x8030d4000) libXcursor.so.1 = /usr/local/lib/libXcursor.so.1 (0x8031e6000) libXcomposite.so.1 = /usr/local/lib/libXcomposite.so.1 (0x8032f) libXdamage.so.1 = /usr/local/lib/libXdamage.so.1 (0x8033f3000) libpangoft2-1.0.so.0 = /usr/local/lib/libpangoft2-1.0.so.0 (0x8034f5000) libXfixes.so.3 = /usr/local/lib/libXfixes.so.3 (0x803627000) libpixman-1.so.9 = /usr/local/lib/libpixman-1.so.9 (0x80372d000) libxcb-shm.so.0 = /usr/local/lib/libxcb-shm.so.0 (0x8038ac000) libxcb-render.so.0 = /usr/local/lib/libxcb-render.so.0 (0x8039ae000) libXrender.so.1 = /usr/local/lib/libXrender.so.1 (0x803ab6000) libX11.so.6 = /usr/local/lib/libX11.so.6 (0x803bbf000) libxcb.so.2 = /usr/local/lib/libxcb.so.2 (0x803df4000) libXau.so.6 = /usr/local/lib/libXau.so.6 (0x803f0e000) libXdmcp.so.6 = /usr/local/lib/libXdmcp.so.6 (0x804011000) libpthread-stubs.so.0 = /usr/local/lib/libpthread-stubs.so.0 (0x804116000) librpcsvc.so.5 = /usr/lib/librpcsvc.so.5 (0x804217000) libfontconfig.so.1 = /usr/local/lib/libfontconfig.so.1 (0x80432) libfreetype.so.9 = /usr/local/lib/libfreetype.so.9 (0x804453000) libexpat.so.6 = /usr/local/lib/libexpat.so.6 (0x8045db000) libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x8046ff000) libpcre.so.0 = not found (0x0) libpcre.so.0 = not found (0x0) libpcre.so.0 = not found (0x0) libpcre.so.0 = not found (0x0) libpcre.so.0 = not found (0x0) libpcre.so.0 = not found (0x0) libpcre.so.0 = not found (0x0) libbz2.so.4 = /usr/lib/libbz2.so.4 (0x8048fa000) libpcre.so.0 = not found (0x0) libORBit-2.so.0 = /usr/local/lib/libORBit-2.so.0 (0x804a0a000) libpcre.so.0 = not found (0x0) libpcre.so.1 =
Re: Need a little help with a dynamic linking problem
Without being able to look at the details in-depth myself, it looks like the shared object is looking for a symbol which the RTLD can't resolve. The symbol is defined in the gthumb application itself. Is that symbol exported such that shared objects can reference it? If the problem is still unresolved by tomorrow, I can draft up a sample and confirm my suspicions (that non-exported symbols won't be resolvable by dynamically-loaded shared objects). Thanks, Shawn Sent from my Android 4.0 device. Please forgive any spelling or grammatical errors. On Apr 25, 2012 6:02 PM, Ronald F. Guilmette r...@tristatelogic.com wrote: My question relates to a port that I am doing of gthumb v2.14.3 to FreeBSD. Because gthumb is fundamentally a gnome application, I am cross-posting my question to both the ports and gnome mailing lists. (My apologies if that means that some of you see this twice.) After a modest but unexpected amount of gnashing of teeth and tearing of hair, I have been able to get gthumb 2.14.3 built and installed on my FreeBSD 8.2 system. Now comes to the fun part... I have installed the whole thing under a special (temporary) directory that I created called /usr/local/hacked. When I try to run the gthumb binary that I built and install, I am getting the following perplexing error message: /libexec/ld-elf.so.1: /usr/local/hacked/lib/gthumb/extensions/libfile_viewer.so: Undefined symbol gth_viewer_page_get_type Quite obviously, I have been away from working on the GNU software development toolchain (and its friends, like ld-elf.so) for far far too long, because I no longer even know how this stuff is even supposed to work, i.e. when it is (knock on wood) working correctly. So if someone who knows this stuff can take pity on me and pass me a clue about what I need to do to resolve the above dynamic linking failure, I sure would appreciate it. Some relevant background: The main gthumb binary is installed in /usr/local/hacked/bin/gthumb and that's what I am running when I run it. It seems pretty obviously to me that the main gthumb executable, when executed, is then trying to dynamically pull in various of the *.so shared library files that got installed into /usr/local/hacked/lib/gthumb/extensions directory as part of the nominal build+install process for gthumb. One last important point: I've checked, and the symbol gth_viewer_page_get_type _is_ in fact defined. It is defined within the main gthumb executable itself: % nm gthumb | fgrep gth_viewer_page_get_type 004aaf10 T gth_viewer_page_get_type So, um, sombody please pass me a clue... How come the dynamic linker doesn't seem to know that the symbol it is looking for was and is defined in the main executable file that the present process originated with? (This specific lack of cognition on the part of the dynamic linker seems to me to be rather reminicent of Alzheimer's.) Regards, rfg P.S. I have already tried both of the following commands prior to executing my gthumb executable and neither of these made a bit of difference to the outcome. I still got the exact same dynamic linker (fatal) error in both cases... setenv LD_LIBRARY_PATH /usr/local/hacked/bin setenv LD_LIBRARY_PATH /usr/local/hacked/lib/gthumb/extensions ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Need a little help with a dynamic linking problem
In message CADt0fhw=cOrwaAmb8VNDRbCnwAuzhRyu=n3l_so732epv1v...@mail.gmail.com , you wrote: Without being able to look at the details in-depth myself, it looks like the shared object is looking for a symbol which the RTLD can't resolve. That much seems self-evident. The error message itself in effect says precisely that. The symbol is defined in the gthumb application itself. Is that symbol exported such that shared objects can reference it? Based on the outcome, I would have to say that this answer to that question is also (self-evidently?) no. But I'm really not sure, frankly, because I have never before seen an instance of anybody trying to do something screwy like this... I mean having a shared library that depends upon somthing (a symbol) that is intended to be satisfied by the main executable. Frankly, this seems altogether screwy and bizzare to me. Unsually, the main executable depends on (or uses, dynamically) a number of shared libraries. Sharded libraries in turn typically depend on either (a) nothing at all or else (b) some combination of other shared and/or static linking libraries. That has always been my own past experience anyway. By like I said, I have been away from the software development tools for awhile, so mabe having a dynamic library that depends upon something in the main executable is considered kosher now. (Or maybe it ain't, actually, but it is nonthelwess one of those screwy things that the current or original developer or maintainer found out that he could get away with anyway, you know, like JUST over on that well-known hobbist OS whose name begins with the letter L.) Like I say. I don't know, cuz I'm not the developer/maintainer of this thing. If the problem is still unresolved by tomorrow... It doesn't seem to be healing on its own so far... I can draft up a sample and confirm my suspicions (that non-exported symbols won't be resolvable by dynamically-loaded shared objects). Oh, I do believe that you are 100% correct about that. This much, at least, I _do_ remember from ancient times when I worked on the GNU software develop- ment tools (including the linker). In every object file... either a main executable or a shared library, there are symbols that are externally available/visible and then there are ones that aren't... i.e. that are local, and that the dynamic linker either never sees or, at any rate, doesn't pay any attention to. But my dim recollection is that you can easily tell which is which by looking at the type letter that appears next to the symbol in the `nm' output. For example: % nm gthumb | fgrep gth_viewer_page_get_type 004aaf10 T gth_viewer_page_get_type ^ Here, the symbol type indicator is the letter `T', meaning that this is a ``text'' (executable/code) type of symbol. That much I know for sure. The part I am less clear about anymore is that I _think_ I remember that when the type letter on the nm output is a capital letter (as in this case) it means that the symbol in question is ``public'' and available for linking. (Actually, I _am_ pretty darn sure that this is indeed what CAPITAL type letters in the nm output mean.) The only other thing that I can't quite remember anymore is whether such a symbol is always and necessarily available for *dynamic* linking purposes. It might perhaps just be externally available visible ONLY for *static* linking purposes, in which case that might explain why I am seeing a `T' on the nm output for the required symbol, but yet the dynamic linker clearly can't seem to find it. Regards, rfg ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Need a little help with a dynamic linking problem
On Apr 25, 2012, at 5:01 PM, Ronald F. Guilmette wrote: When I try to run the gthumb binary that I built and install, I am getting the following perplexing error message: /libexec/ld-elf.so.1: /usr/local/hacked/lib/gthumb/extensions/libfile_viewer.so: Undefined symbol gth_viewer_page_get_type Does running ldconfig /usr/local/hacked/lib help? What does ldd say about things? Regards, -- -Chuck ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
