Dechenjm / crack-language

Automatically exported from code.google.com/p/crack-language
Other
0 stars 0 forks source link

Add support for linking in crackc #91

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
(Enhancement)

Hello!
The crack compiler (crackc) needs support for linking libraries.
For instance, if I want to compile a crack program that needs GTK+ to work, the 
following command fail:
crackc program.crk
I got theses errors:
/usr/bin/ld: /usr/lib/crack-0.6/crack/_gtk.so: undefined reference to symbol 
'gtk_button_new'
/usr/bin/ld: note: 'gtk_button_new' is defined in DSO /usr/lib/libgtk-3.so.0 so 
try adding it to the linker command line
/usr/lib/libgtk-3.so.0: could not read symbols: Invalid operation
collect2: ld a retourné 1 code d'état d'exécution

Now, I need to compile manually with something like:
crackc program.crk
(it fails, but it creates program.o)
and next:
/usr/bin/gcc -O3 -m64 `pkg-config gtk+-3.0 --libs` -o program program.o -L. 
-Wl,-rpath=/path/to/my/project -L/usr/lib/crack-0.6 
-Wl,-rpath=/usr/lib/crack-0.6 -L/usr/lib/crack-0.6/crack 
-Wl,-rpath=/usr/lib/crack-0.6/crack -L/usr/lib/crack-0.6/crack 
-Wl,-rpath=/usr/lib/crack-0.6/crack -l:runtime.so -l:_gtk.so 
-lCrackNativeRuntime

It would be nice to be able to "inject" text to the command line running gcc.
For instance, I would like to add this:
`pkg-config gtk+-3.0 --libs`
and crackc will add this to the command running gcc.

Thanks.

Original issue reported on code.google.com by boua...@mailinator.com on 14 Dec 2011 at 3:27

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
What's the output of ldd on _gtk.so?

Original comment by weyrick on 14 Dec 2011 at 5:50

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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: