On 10/5/2013 05:46, Jon wrote: > > In addition to LRN's awesome feedback, here are a few other comments... > > 1) Hold off spelunking autotools (aka AutoHell) until you're comfortable > with gcc/g++, ld, binutils, and make. Autotools is the Quasimodo of > software tools. Horrific to look at but incredibly powerful. It and the > people who developed it and continue to support it deserve your respect. > The documentation is very good and will help you understand triplets, > --build, --host, and --target mentioned by LRN. > > https://www.gnu.org/software/autoconf/manual/index.html >
You bet it is the very best, developed for and by developers that
understand the GNU toolchain.
> 2) Write an insanely simple program and practice with your tools until
> you're familiar with their capabilities. For example, with this trivial C++
> program
>
> # file: hello.cc
> #include <iostream>
>
> static void say_hello()
> {
> std::cout << "Hello C++ World!" << std::endl;
> }
>
> int main() {
> say_hello();
>
> return 0;
> }
>
> start playing, and keep playing, until you learn more about the tools. GDB
> is a great friend, but I won't show it below. These examples are from my
> Win8 64bit on a W530 using an official MinGW-w64 64bit binary toolchain
> (win32 threading, SEH exception handling) built and maintained by the
> fabulous niXman and Alexey.
>
> C:\Users\Jon\Documents\CDev\sandbox>gcc --version
> gcc (rev2, Built by MinGW-W64 project) 4.8.1
> ...
>
> # basic use of g++ compiler driver (why did I call it a "compiler driver?")
> C:\Users\Jon\Documents\CDev\sandbox>g++ -Wall -o hello.exe hello.cc
>
Because g++ drives the real compiler "cc1plus" in the background, the
user should not use it directly.
> # eh? gcc can compile C++ programs?
> C:\Users\Jon\Documents\CDev\sandbox>gcc -Wall -o hello.exe hello.cc -lstdc++
>
It can, but you noticed you need to specify language support libraries
at the end. This is take care of automatically by g++, likewise if you
use other drivers like gfortran.
> # use g++ or it's prefixed version
> C:\Users\Jon\Documents\CDev\sandbox>x86_64-w64-mingw32-g++ -Wall -o
> hello.exe hello.cc
>
Preferably use g++ over gcc when C++ is involved.
> # eh? why doesn't this work!?
> C:\Users\Jon\Documents\CDev\sandbox>g++ -Wall -m32 -o hello.exe hello.cc
> c:/apps/devtools/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe:
> skipping incompatible
> c:/apps/devtools/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/libstdc++.dll.a
> when searching for -lstdc++
> ...
> bin/ld.exe: skipping incompatible
> c:/apps/devtools/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/lib/libmsvcrt.a
> when searching for -lmsvcrt
> c:/apps/devtools/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe:
> cannot find -lmsvcrt
> collect2.exe: error: ld returned 1 exit status
>
Because not the entire toolchain is not multilib capable.
> # ...but this works?
> C:\Users\Jon\Documents\CDev\sandbox>g++ -Wall -m64 -o hello.exe hello.cc
>
Ditto, -m32 means 32bit, -m64 means 64bit, toolchain is not complete for
32bit case.
> # maybe g++ will give us the reason if we cause it to spew out enough info
> # what's that `--disable-multilib` configuration option and `Target:
> x86_64-w64-mingw32`
> # and `--host=x86_64-w64-mingw32` and `--target=x86_64-w64-mingw32`
> configuration
> # options used when g++ was built?
> C:\Users\Jon\Documents\CDev\sandbox>g++ -v
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=c:/apps/devtools/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.1/lto-wrapper.exe
> Target: x86_64-w64-mingw32
> Configured with: ../../../src/gcc-4.8.1/configure --host=x86_64-w64-mingw32
> --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
> --with-sysroot=/tmp/x86_64-481-win32-seh-rt_v3-r2/mingw64 --enable-shared
> --enable-static --disable-multilib
^^^^^^^^^^^^^^^^^^
>
> # all the following examples using binutils tools have documentation
> available at
> https://sourceware.org/binutils/
> https://sourceware.org/binutils/docs-2.23.1/binutils/index.html
> https://sourceware.org/binutils/docs-2.23.1/binutils/nm.html#nm
> https://sourceware.org/binutils/docs-2.23.1/binutils/objdump.html#objdump
> https://sourceware.org/binutils/docs-2.23.1/ld/index.html
>
> # I've heard my 'say_hello' function has a symbol; show me (assumes you're
> using MSYS/MSYS2 for `grep`)
> # what's the small case `t` in front of the symbol name mean?
> # what would it mean if it was a capital `T`?
> C:\Users\Jon\Documents\CDev\sandbox>nm -A --defined-only hello.exe | grep
> say_hello
> hello.exe:00000000004014f0 t _ZL9say_hellov
>
T means .text section, externally visible. t means .text section, not
visible outside the translation unit, your static qualifier caused that.
See nm manual or "man nm" if you have man installed.
> # eh? I didn't write a `_ZL9say_hellov` function; what's wrong? => C++ name
> mangling...pretty print please
> C:\Users\Jon\Documents\CDev\sandbox>nm -A -C --defined-only hello.exe |
> grep say_hello
> hello.exe:00000000004014f0 t say_hello()
>
C++ name demangling done through c++filt program. Try nm ... | c++filt
or c++filt _ZL9say_hellov.
> # give me more info about the executable.
> # hey, what's that `file format pei-x86-64` or `i386:x86-64` mean?
> C:\Users\Jon\Documents\CDev\sandbox>objdump -x hello.exe
>
The format of the executable is designated pei-x86-64, which is
basically the PE32+ format. The architecture bits are set to
i386:x86-64, PE has support for ARM and Alpha too. Windows will not
blindly try to run
See docs at
<http://msdn.microsoft.com/en-us/windows/hardware/gg463119.aspx>.
> # get quick info on the executable file (assumes you're using MSYS/MSYS2
> for `file`)
> C:\Users\Jon\Documents\CDev\sandbox>file hello.exe
> hello.exe: PE32+ executable (console) x86-64, for MS Windows
>
> # `objdump` shows me this Import Table info, what does it all mean?
> C:\Users\Jon\Documents\CDev\sandbox>objdump -x hello.exe
Means symbols imported at runtime by the PE loader from other
executable. These typically contain jump stubs that get resolved to the
real addresses when the program starts, after at which all calls are
jumped to the real address. See the PE/COFF spec docs link above.
>
> Good luck with spelunking the awesomeness that makes up your MinGW-w64
> toolchain.
>
Do go on.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
