Open GoogleCodeExporter opened 9 years ago
Hi, thanks for the report. We've so far been relying on the fact that _gtk.so
itself should already be linked to libgtk-3.so.0, and therefore ld should
transitively link it during the call that crackc makes as well. I haven't
verified this with the gtk extension, but it does work that way with the pcre
extension in our tests on Ubuntu Linux 11.04 and 11.10.
It seems that relying on this functionality may not be sufficient for all
platforms, though.
What platform/distribution are you using? Are you able to compile a script that
uses pcre (crack.regex) without linker errors? I'd like to determine if perhaps
it's the way we're compiling the gtk extension, or if transitive linking isn't
working the same on your platform.
Original comment by weyrick
on 14 Dec 2011 at 5:37
What's the output of ldd on _gtk.so?
Original comment by weyrick
on 14 Dec 2011 at 5:50
As a side note, this works for me with GTK 2.0. As weyrick said, no additional
link options should be necessary. The autoconf build doesn't know about GTK
3.0, how did you build the GTK extension?
I agree that there might be cases where this feature (specifying link
libraries) is actually desirable - if only to hack around poorly built
extensions.
Original comment by mmul...@google.com
on 14 Dec 2011 at 5:54
I use ArchLinux.
I am unable to compile a program using regexes.
I got these errors:
/usr/bin/ld: /usr/lib/crack-0.6/crack/ext/_pcre.so: undefined reference to
symbol 'pcre_compile2'
/usr/bin/ld: note: 'pcre_compile2' is defined in DSO /lib/libpcre.so.0 so try
adding it to the linker command line
/lib/libpcre.so.0: could not read symbols: Invalid operation
collect2: ld a retourné 1 code d'état d'exécution
When looking for this problem on the Internet, I found that link :
http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
Maybe it can help you understand the problem.
WARNING: I completely changed the GTK+ extension because I want to continue the
wrapper.
I compiled my GTK+ extension with this script:
gcc -c -fPIC _gtk.cpp `pkg-config gtk+-3.0 --cflags` -o _gtk.o
gcc -shared -fPIC _gtk.o `pkg-config gtk+-3.0 --libs` -o _gtk.so
sudo mv _gtk.so /usr/lib/crack-0.6/crack/
sudo cp gtk.crk /usr/lib/crack-0.6/crack/
sudo cp gtk/* /usr/lib/crack-0.6/crack/gtk
ldd _gtk.so outputs:
linux-vdso.so.1 => (0x00007fffb05cf000)
libgtk-3.so.0 => /usr/lib/libgtk-3.so.0 (0x00007ff2598a4000)
libgdk-3.so.0 => /usr/lib/libgdk-3.so.0 (0x00007ff259628000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00007ff259405000)
libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007ff2590c5000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00007ff258e99000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007ff258c8b000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00007ff258a69000)
libcairo-gobject.so.2 => /usr/lib/libcairo-gobject.so.2 (0x00007ff258861000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007ff2585b2000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00007ff258367000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007ff2580c9000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007ff257e94000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007ff257c44000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007ff257a40000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007ff25783a000)
librt.so.1 => /lib/librt.so.1 (0x00007ff257632000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007ff25733d000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007ff257126000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007ff256f09000)
libc.so.6 => /lib/libc.so.6 (0x00007ff256b82000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007ff256845000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007ff25663f000)
libm.so.6 => /lib/libm.so.6 (0x00007ff2563bd000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007ff2561aa000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007ff255fa8000)
libXi.so.6 => /usr/lib/libXi.so.6 (0x00007ff255d99000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007ff255b8f000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007ff255985000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x00007ff255783000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007ff255580000)
libffi.so.5 => /usr/lib/libffi.so.5 (0x00007ff255378000)
libdl.so.2 => /lib/libdl.so.2 (0x00007ff255173000)
libpcre.so.0 => /lib/libpcre.so.0 (0x00007ff254f19000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007ff254d00000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00007ff254ae8000)
libpng14.so.14 => /usr/lib/libpng14.so.14 (0x00007ff2548bf000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x00007ff254636000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007ff25442c000)
libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00007ff25421b000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007ff253ff1000)
/lib/ld-linux-x86-64.so.2 (0x00007ff25a125000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007ff253dd5000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007ff253bd3000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007ff2539cd000)
Original comment by boua...@mailinator.com
on 14 Dec 2011 at 5:56
It does sound like this change has been implemented and is currently wrecking
my day :-). Can you try your hack to build the final executable only without
specifying the secondary shared libraries but instead adding the --add-needed
flag before the other shared libraries? I think we might be able to use this
as a work-around.
Original comment by mmul...@google.com
on 14 Dec 2011 at 6:40
Actually, that would probably be -Wl,--add-needed to be used from gcc
Original comment by mmul...@google.com
on 14 Dec 2011 at 6:42
I can confirm that adding -Wl,--add-needed to the gcc command launched by
crackc resolve the linking problem.
For instance, with that command, I don't have to link GTK+:
/usr/bin/gcc -O3 -m64 -o program program.o -L.
-Wl,--add-needed,-rpath=/path/to/my/project -L/usr/lib/crack-0.6
-Wl,--add-needed,-rpath=/usr/lib/crack-0.6 -L/usr/lib/crack-0.6/crack
-Wl,--add-needed,-rpath=/usr/lib/crack-0.6/crack -L/usr/lib/crack-0.6/crack
-Wl,--add-needed,-rpath=/usr/lib/crack-0.6/crack -l:runtime.so -l:_gtk.so
-lCrackNativeRuntime
Original comment by boua...@mailinator.com
on 14 Dec 2011 at 6:52
Good! The attached patch should provide a work-around.
We'll add a more permanent fix after some further consideration on whether we
want to try something more platform independent.
Original comment by mmul...@google.com
on 14 Dec 2011 at 7:40
Attachments:
Sorry, I double-pasted the change - the attached patch is correct.
Original comment by mmul...@google.com
on 14 Dec 2011 at 7:42
Attachments:
Original issue reported on code.google.com by
boua...@mailinator.com
on 14 Dec 2011 at 3:27