I try to compile a very simple GtkAda application in command-line, on Windows. Here is the app code:
`WITH Gtk.Main ; USE Gtk.Main ;
WITH Gtk.Window ; USE Gtk.Window ;
PROCEDURE Test01 IS
win : Gtk_window ;
BEGIN
Init ;
Gtk_New(Win) ;
Win.show_all ;
Main ;
END Test01 ;`
Compiling with
gcc -c test01.adb -IC:\<<path_to_GtkAda\include\gtkada>>,
I obtain test.ali and test01.o as expected.
But how to link the libs please?
gcc test.o -LC:\<<path_to_GtkAda>>\lib
gives:
`Test01.o:Test01.adb:(.text+0xe): undefined reference to `gtk__main__init'
Test01.o:Test01.adb:(.text+0x21): undefined reference to `gtk__window__gtk_new'
Test01.o:Test01.adb:(.text+0x3e): undefined reference to `__gnat_rcheck_CE_Access_Check'
Test01.o:Test01.adb:(.text+0x5e): undefined reference to `gtk__main__main'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: Test01.o: bad reloc address 0x20 in section `.eh_f
rame'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status`
PATH already contains <<path_to_GtkAda>>/bin
Thank you.
The solution usually is to use GNAT's project files as described in the documentation installed with the compiler, typically in the “doc” or "doc/gprbuild” subdirectory.
A simple example project file named “SO.gpr” might look like this:
with "gtkada";
project SO is
for Source_Dirs use (".");
end SO;
Note the part that says with "gtkada";. It means that the toolchain then will inject all switches that are necessary to make an Ada/GTK program.
Then, if you invoke the GNAT toolchain like this:
$ gnatmake -PSO test01.adb
the Ada make program will call, in sequence, gcc, gnatbind, and gnatlink. For each, the necessary arguments to the commands will be supplied automatically.
(Depending on which edition of GNAT you are using, you may also use gprbuild.)
So, for example on a Debian/GNU system with libgtkada2.24.4-dev installed, I see this:
$ gnatmake -Pso test01.adb
gcc-4.9 -c -I- -gnatA /home/bauhaus/News/SO/test01.adb
gnatbind -shared -x /home/bauhaus/News/SO/test01.ali
gnatlink /home/bauhaus/News/SO/test01.ali -shared-libgcc -L/usr/lib/x86_64-linux-gnu/ -lgtkada -lgdk-x11-2.0 -lgmodule-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lfontconfig -lfreetype -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lX11 -lm -o /home/bauhaus/News/SO/test01
$
Related
I'm quite new to assembly programming. I use NASM 2.11.05 on a Windows 7 (64-bit) platform to run some sample code. The problem arises when I try to call standard C functions from my assembly code. This is my assembly source:
global main
extern puts
section .text
main:
push message
call puts
ret
message:
db "Hola, mundo", 0
When I compile with NASM, I use this command line: nasm -fwin32 file.asm
which produces file.obj. Now, when I try to link it with ld or gcc, I keep getting errors. Some things I tried:
gcc -m32 -nostartfiles file.obj (gives the error that i386:x86-64 architecture of input file is not compatible with i386 output).
ld file.obj (gives the error undefined reference to puts).
Can anyone please guide me on how to resolve this?
In the end, one line at the top of my ASM file settled it. This is that line.
[BITS 32]
However, the output file still keeps crashing: anyone who can explain that is welcome!
You can just compile in a different way, like:
Create an object of your .asm file with:
GCC: nasm -f elf file.asmor
LD: ld -m elf_i386 file.o -o file
Link object file created with gcc -m32 -o file file.o
Run with ./file
I'm trying to compile w3m for Windows XP using MinGW or TDM-GCC. After applying the patch at W3m patch - Linux from scratch and adding -lws2_32 to LIBS at Makefile I have come across these 5 Windows-incompatible functions (in the order of first appearance)
bcopy (at Str.c)
sleep (at file.c)
kill (at image.c)
open_pipe_rw (at image.c)
fork (at image.c)
I have fixed the first two by defining their Windows equivalents like:
void bcopy(const void *from, void *to, size_t n) {
int *dummy;
dummy = memcpy(to, from, n);
}
#define sleep(n) Sleep(n*1000)
After these, all object files were compiled fine but those three Unix functions being called from image.o prevented w3m.exe from being formed at the linking stage:
$ make
(cd libwc && make CC='gcc' OPTS='')
make[1]: Entering directory '/c/Documents and Settings/ibm/Downloads/w3m-0.5.3/libwc'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/c/Documents and Settings/ibm/Downloads/w3m-0.5.3/libwc'
gcc -I. -I. -g -O2 -I./libwc -IC:/msys32/usr/local/include -DHAVE_CONFIG_H -DAUXBIN_DIR=\"/usr/local/libexec/w3m\"
-DCGIBIN_DIR=\"/usr/local/libexec/w3m/cgi-bin\" -DHELP_DIR=\"/usr/local/share/w3m\" -DETC_DIR=\"/usr/local/etc\" -DCONF_DIR=\"/usr/local/etc/w3m\"
-DRC_DIR=\"~/.w3m\" -DLOCALEDIR=\"/usr/local/share/locale\"
-o w3m.exe main.o file.o buffer.o display.o etc.o search.o linein.o
table.o local.o form.o map.o frame.o rc.o menu.o mailcap.o image.o
symbol.o entity.o terms.o url.o ftp.o mimehead.o regex.o news.o func.o
cookie.o history.o backend.o keybind.o anchor.o parsetagx.o tagtable.o
istream.o version.o -lws2_32 -lpthread -L. -lindep -lgc -L./libwc -lwc
-LC:/msys32/usr/local/lib -lssl -lcrypto -lssl -lcrypto -lncurses
./libindep.a(indep.o): In function `bcopy':
C:\Documents and Settings\ibm\Downloads\w3m-0.5.3/indep.c:74: multiple definition of `bcopy'
./libindep.a(Str.o):C:\Documents and Settings\ibm\Downloads\w3m-0.5.3/Str.c:36: first defined here image.o: In function `closeImgdisplay':
C:\truncated\w3m-0.5.3/image.c:126: undefined reference to `kill'
image.o: In function `openImgdisplay':
C:\truncated\w3m-0.5.3/image.c:93: undefined reference to `open_pipe_rw'
image.o: In function `loadImage':
C:\truncated\w3m-0.5.3/image.c:354: undefined reference to `kill'
C:\truncated\w3m-0.5.3/image.c:383: undefined reference to `kill'
C:\truncated\w3m-0.5.3/image.c:436: undefined reference to `fork'
collect2.exe: error: ld returned 1 exit status
Makefile:130: recipe for target 'w3m.exe' failed
make: *** [w3m.exe] Error 1
How can I define the Windows equivalents of those three Unix functions? If you can suggest any other solution like giving specific options to or editing the configure command and/or Makefile so that the image.c uses the Windows equivalents of those functions, that's fine too. Thanks.
Build the program for Cygwin; then turn it into a native application with Cygnal by bundling it together with the Cygwin DLL's it needs, but with cygwin1.dll from Cygnal instead of Cygwin.
Cygwin has fork, kill and numerous other POSIX functions.
Also, Cygwin provides bi-directional ANSI/VT100 emulation, right over the Windows Console API. This means that programs that interact with terminals using raw escape sequences will work—right out of the cmd.exe console window. The POSIX termios function work nicely for setting up character-at-a-time input and all that.
I'm trying to compile GNU Source highlight in my home directory.
I configured with a prefix and --with-boost=/path/to/boost/root/dir/ and no errors were reported.
But when I try to build I got the following error:
$ make
... # lots of output
libtool: link: g++ -shared -nostdlib /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbeginS.o .libs/copyright.o .libs/reportbugs.o .libs/fileutil.o .libs/substfun.o .libs/stopwatch.o .libs/utils.o .libs/ioexception.o .libs/settings.o .libs/versions.o .libs/verbosity.o .libs/sourcehighlight.o .libs/styleparser.o .libs/stylescanner.o .libs/outlangdefparser.o .libs/stylecssparser.o .libs/stylecssscanner.o .libs/outlangdefscanner.o .libs/debuglistener.o .libs/langmap.o .libs/stylefileparser.o .libs/langelem.o .libs/statelangelem.o .libs/langelems.o .libs/statestartlangelem.o .libs/stringlistlangelem.o .libs/delimitedlangelem.o .libs/langelemsprinter.o .libs/namedsubexpslangelem.o .libs/stringdef.o .libs/highlightrule.o .libs/highlighttoken.o .libs/highlightstate.o .libs/highlightrulefactory.o .libs/highlightstateprinter.o .libs/sourcehighlighter.o .libs/sourcefilehighlighter.o .libs/linenumgenerator.o .libs/lineranges.o .libs/regexranges.o .libs/formatter.o .libs/formattermanager.o .libs/textstyle.o .libs/textstyleformatter.o .libs/bufferedoutput.o .libs/preformatter.o .libs/wordtokenizer.o .libs/ctagscollector.o .libs/readtags.o .libs/ctagsformatter.o .libs/srcuntabifier.o .libs/textstyleformatterfactory.o .libs/docgenerator.o .libs/doctemplate.o .libs/chartranslator.o .libs/textstylebuilder.o .libs/fileinfo.o .libs/ctagsmanager.o .libs/regexhighlightrule.o .libs/regexrulefactory.o .libs/regexpreprocessor.o .libs/highlightstatebuilder.o .libs/highlightbuilderexception.o .libs/langdefmanager.o .libs/langdefparser.o .libs/langdefscanner.o .libs/languageinfer.o .libs/parserexception.o .libs/stringtable.o .libs/vardefinitions.o .libs/sourcehighlightutils.o .libs/yywrap.o -Wl,--whole-archive ../../gl/.libs/libgnu.a -Wl,--no-whole-archive -lboost_regex -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o -Wl,-soname -Wl,libsource-highlight.so.1 -o .libs/libsource-highlight.so.1.1.0
/usr/bin/ld: cannot find -lboost_regex
collect2: ld returned 1 exit status
Note that, I have Boost loaded in my environment, in fact:
$ echo $LD_LIBRARY_PATH
/path/to/boost/root/dir/lib:/other/path/lib
and ls shows that /path/to/boost/root/dir/lib/libboost_regex.so exists and is a symbolic link to libboost_regex.so.1.47.0
How is this possible? How can I solve it?
At linking time, the correct environment variable to use to define the path where to find the libraries is LIBRARY_PATH, not LD_LIBRARY_PATH. The former is equivalent to specifying -L in the gcc arguments, while the latter is used at runtime, like PATH, to find the binary executables. See this for more information.
I have a problem with following code.
extern printf
global _main
main:
push msg
call printf
ret
msg db "Hello world",0
I assemble this with NASM using nasm -fwin32 test.asm Then i link it using ld test.obj.
And it tells me "test.obj:test.asm:(text+0x6): undefined reference to 'printf'"
How to link my file to standard C libraries? I have ld from latest MinGW.
To assemble code :
nasm -fwin32 test.asm
Microsoft will prefix functions using the cdecl calling convention with a underscore.
To be match to the C calling convention printf should be _printf.
The same applies for _main instead of main.
And link with:
ld test.obj -lmsvcrt -entry=_main -subsystem=console -o test.exe
Here -entry command line option is used to invoking ld to specify the entry point for program .
Then use -l options to pass msvcrt library to the ld linker, otherwise you will get an error message, (undefined reference to `printf') which means that the linker did not found the symbol printf in the specified object file produced by NASM.
Here is completed source:
global _main
extern _printf
section .text
_main:
push msg
call _printf
add esp, 4 ;adjust the stack
ret
msg db "Hello world",0
I can see several issues with your code. First, you've got an underscore on global _main but not on main:. These should match. You can either use underscores throughout, or - what I would do - not at all... and for Windows, assemble as nasm -f win32 --prefix _ test.asm. This would make it "portable" in that, for Linux, it would assemble, without the --prefix _ without the underscores. Linux doesn't use underscores on global or extern symbols. If, by some chance, you were using OpenWatcom C, you could use --postfix _. Yeah, OpenWatcom uses trailing underscores. Yeah, I know they told us C was standardized. but once you get under the hood, this isn't really true.
The other big issue is that after calling _printf, you need to add esp, 4 (or pop a dummy register) to "clean up the stack". If you're using Windows APIs, they use the STDCALL calling convention in which "callee cleans up", so you don't want to do this. Mixing C calls (CDECL calling convention) and Windows APIs might get confusing, but should work.
I think Carl has the right idea with using gcc to link it. There's nothing to "compile", but gcc knows the proper command line to ld. gcc -o test.exe test.obj will probably be enough (maybe add -m32 if the latest MinGW expects to be doing 64-bit code). This will link in some "startup code" which calls _main. This will increase the size of your executable slightly, and you "might" be able to get along without it, but it's easier to just do it.
In Linux, we can use ld directly (the command line is horrid), but ld is looking for _start, not main, as the entrypoint. We can tell ld -e main, but this entrypoint is not called(!) and there's no possible way to ret from it! The situation is probably different in Windows. You would need - as a bare minimum - -lc to tell ld that we want those C libraries. Easiest to "let gcc do it" - it won't touch your .asm code (but does link in that "startup code"). Happy Hello World! :)
Use a compiler front-end to link:
cc test.obj
If you really want to use ld directly (and you shouldn't), use the -v flag to cc to figure out what complete command line you need. For example, on my machine, it's:
ld -demangle -dynamic -arch x86_64 -macosx_version_min 10.8.0 \
-o a.out test.obj -lSystem \
/usr/bin/../lib/clang/4.2/lib/darwin/libclang_rt.osx.a
If I use GCC instead of Clang, it's even crazier:
ld -dynamic -arch x86_64 -macosx_version_min 10.8.4 -weak_reference_mismatches \
non-weak -o a.out -lcrt1.10.6.o \
-L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64 \
-L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/x86_64 \
-L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1 \
-L/usr/llvm-gcc-4.2/bin/../lib/gcc \
-L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1 \
-L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../.. \
-L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/../../.. \
test.obj -lgcc -lSystem
I'm having trouble building a project that attempts to check for the presence of shm_open and shm_unlink. The relevant lines of configure.ac are:
# Avoid adding rt if absent or unneeded
AC_CHECK_LIB(rt, shm_open, [EXTRA_LIBS="$EXTRA_LIBS rt" CFLAGS="$CFLAGS -lrt"])
# needs -lrt on linux
AC_CHECK_FUNCS([shm_open shm_unlink])
The AC_CHECK_LIB line succeeds, however AC_CHECK_FUNCS fails for both. Looking in config.log, I see
configure:4133: checking for shm_open in -lrt
configure:4158: /usr/bin/gcc -o conftest -fno-stack-protector -Wl,--hash-size=31 -Wl,--reduce-memory-overheads conftest.c -lrt >&5
configure:4158: $? = 0
configure:4167: result: yes
configure:4178: checking for shm_open
configure:4178: /usr/bin/gcc -o conftest -fno-stack-protector -lrt -Wl,--hash-size=31 -Wl,--reduce-memory-overheads conftest.c >&5
/tmp/ccg0yu56.o: In function `main':
conftest.c:(.text+0xa): undefined reference to `shm_open'
collect2: ld returned 1 exit status
It appears that the only difference between the two checks is the position of the -lrt argument. When I try running gcc on a simple file manually, I get the same behavior, i.e. linking succeeds only when -lrt comes after the source file input.
So, what do I need to do so configure will determine that shm_open and shm_unlink exist? I suspect this is something particular to my system, as the project I'm configuring is pretty widely used (the unix package bundled with the ghc compiler), and it used to work (when I built this package on a different system with gcc-4.4.5, it worked, however that environment is no longer available). My preferred solution would be either a change to the system/environment or some combination of flags to configure, however if there's a standard modification for configure.ac that I could send upstream, that's acceptable also.
I've tried various combinations of CFLAGS and LDFLAGS, but the -lrt flag always appears before the input file, so the check still fails.
My system is Ubuntu 12.04 (precise)
$gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
$ uname -a
Linux hostname 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Thanks!
Macro have full form:
AC_CHECK_LIB (library, function, [action-if-found], [action-if-not-found], [other-libraries])
Please note other-libraries. This option is useful specifically for cases you described -- to pass -lm, -lrt and other common guys to avoid unresolved references in linker ordering.
Check doc page for more information on AC_CHECK_LIB macro