On Fri, Oct 4, 2013 at 11:14 AM, LRN <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04.10.2013 18:15, Incongruous wrote:
> > Which of these compilers should I use if I want to compile in 64bit?
> >
> > <prefix>/bin/g++.exe
> > <prefix>/bin/x86_64-w64-mingw32-g++.exe
> >
> >
> > Is this correct?
> >
> > if(OS_64_BIT){
> > <prefix>/bin/g++.exe
> > }
> > else{
> > <prefix>/bin/x86_64-w64-mingw32-g++.exe
> > }
>
> No.
>
> 1) gcc compiles for its target triplet.
> 2) target triplet is put into prefix (i.e. x86_64-w64-mingw32 is the
> prefix for g++)
> 3) target triplet can be found by invoking `gcc -dumpmachine'
> 4) if gcc has no prefix (i.e. just g++.exe), then -dumpmachine is the
> only way to find the target (well, not really, but this is what you
> should use).
> 5) on sane systems (MSYS2-based sbuild, most GNU systems) `gcc', `g++'
> and other un-prefixed executables are, in fact, symbolic links to real,
> prefixed executables
>
> Another point that you should keep in mind is where gcc looks for libs
> and headers.
> Run `echo | [<gcc executable>] -E -v -' to see where it looks for headers.
> Run `[<gcc executable>] -print-search-dirs' to see where it looks for
> libs (replace [<gcc executable>] with the executable name).
>
> So, your assessment makes no sense. g++ could be the right thing to use.
> Or maybe it isn't. You will never know until you check its target.
> x86_64-w64-mingw32-g++ is not the right thing to use for non-64-bit
> OSes, because it compiles for 64-bit OSes (that is obvious from its
> prefix). Most likely (let's keep it real - usually people don't mix
> unprefixed i686-gcc with prefixed x86_64-gcc) both executables will
> produce x86_64 code.
>
> If you do want to actually compile for i686 and x86_64, you need either
> a multilib toolchain (these are rare; if you do find one, use -m32 and
> - -m64 to set its target) or two separate toolchains.
>
> If toolchains are native, you can't mix them in the same directory, as
> they look in the same directories for libs and headers, and their libs
> are different (but have the same names).
> If toolchains are not native (are cross-compilers; self-targetted or not
> - - that does not matter) you may be able to mix them in the same
> directory, as they look for stuff in <tirplet> subdirectories. Note that
> i have never tried to do that, and generally don't use cross-compilers.
>
> Finally, if you use autotools, then you don't have to select which
> compiler to use, as configure script will do that for you. You only need
> to specify the right --build or --host
>
>
Incongruous, fantastic to see your desire to deeply understand how your
toolchain.
You just need to spend some time connecting all the dots by playing with
the different build tools.
Keep with it and make sure you FIRST try things, fall down, get back up,
and do it again rather than simply lobbing question after question to ML's.
But don't run your head against the wall TOO many times. If you've narrowed
things down to a simple test scenario and it keeps failing no matter what
you try, ask the gurus here. Give them the simple test scenario, your
assumptions, and a brief description of what you've tried.
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
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
# eh? gcc can compile C++ programs?
C:\Users\Jon\Documents\CDev\sandbox>gcc -Wall -o hello.exe hello.cc -lstdc++
# use g++ or it's prefixed version
C:\Users\Jon\Documents\CDev\sandbox>x86_64-w64-mingw32-g++ -Wall -o
hello.exe hello.cc
# 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
# ...but this works?
C:\Users\Jon\Documents\CDev\sandbox>g++ -Wall -m64 -o hello.exe hello.cc
# 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
--enable-languages=ada,c,c++,fortran,objc,obj-c++,lto
--enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp
--enable-lto --enable-graphite --enable-checking=release
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--disable-isl-version-check --disable-cloog-version-check
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona
--with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--with-mpfr=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--with-mpc=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--with-isl=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--with-cloog=/tmp/mingw-prereq/x86_64-w64-mingw32-static
--enable-cloog-backend=isl
--with-pkgversion='rev2, Built by MinGW-W64 project' --with-bugurl=
http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-I/tmp/x86_64-481-win32-seh-rt_v3-r2/libs/include
-I/tmp/mingw-prereq/x86_64-zlib/include
-I/tmp/mingw-prereq/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe
-I/tmp/x86_64-481-win32-seh-rt_v3-r2/libs/include
-I/tmp/mingw-prereq/x86_64-zlib/include
-I/tmp/mingw-prereq/x86_64-w64-mingw32-static/include' CPPFLAGS=
LDFLAGS='-pipe -L/tmp/x86_64-481-win32-seh-rt_v3-r2/libs/lib
-L/tmp/mingw-prereq/x86_64-zlib/lib
-L/tmp/mingw-prereq/x86_64-w64-mingw32-static/lib
-L/tmp/x86_64-481-win32-seh-rt_v3-r2/mingw64/opt/lib '
Thread model: win32
gcc version 4.8.1 (rev2, Built by MinGW-W64 project)
# 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
# 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()
# 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
hello.exe: file format pei-x86-64
hello.exe
architecture: i386:x86-64, flags 0x0000013a:
EXEC_P, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, D_PAGED
start address 0x00000000004014d0
Characteristics 0x27
relocations stripped
executable
line numbers stripped
large address aware
Time/Date Fri Oct 04 17:07:39 2013
Magic 020b (PE32+)
MajorLinkerVersion 2
MinorLinkerVersion 23
SizeOfCode 00001e00
SizeOfInitializedData 00003e00
SizeOfUninitializedData 00000a00
AddressOfEntryPoint 00000000000014d0
BaseOfCode 0000000000001000
ImageBase 0000000000400000
SectionAlignment 0000000000001000
FileAlignment 0000000000000200
MajorOSystemVersion 4
MinorOSystemVersion 0
MajorImageVersion 0
MinorImageVersion 0
MajorSubsystemVersion 5
MinorSubsystemVersion 2
Win32Version 00000000
SizeOfImage 00010000
SizeOfHeaders 00000400
CheckSum 000169d2
Subsystem 00000003 (Windows CUI)
DllCharacteristics 00000000
SizeOfStackReserve 0000000000200000
SizeOfStackCommit 0000000000001000
SizeOfHeapReserve 0000000000100000
SizeOfHeapCommit 0000000000001000
LoaderFlags 00000000
NumberOfRvaAndSizes 00000010
The Data Directory
Entry 0 0000000000000000 00000000 Export Directory [.edata (or where ever
we found it)]
Entry 1 0000000000008000 0000092c Import Directory [parts of .idata]
Entry 2 0000000000000000 00000000 Resource Directory [.rsrc]
Entry 3 0000000000005000 00000264 Exception Directory [.pdata]
Entry 4 0000000000000000 00000000 Security Directory
Entry 5 0000000000000000 00000000 Base Relocation Directory [.reloc]
Entry 6 0000000000000000 00000000 Debug Directory
Entry 7 0000000000000000 00000000 Description Directory
Entry 8 0000000000000000 00000000 Special Directory
Entry 9 000000000000a000 00000028 Thread Storage Directory [.tls]
Entry a 0000000000000000 00000000 Load Configuration Directory
Entry b 0000000000000000 00000000 Bound Import Directory
Entry c 0000000000008230 000001e0 Import Address Table Directory
Entry d 0000000000000000 00000000 Delay Import Directory
Entry e 0000000000000000 00000000 CLR Runtime Header
Entry f 0000000000000000 00000000 Reserved
...
# 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
...
There is an import table in .idata at 0x408000
The Import Tables (interpreted .idata section contents)
vma: Hint Time Forward DLL First
Table Stamp Chain Name Thunk
00008000 00008050 00000000 00000000 00008878 00008230
DLL Name: KERNEL32.dll
vma: Hint/Ord Member-Name Bound-To
8410 216 DeleteCriticalSection
8428 248 EnterCriticalSection
8440 461 GetCurrentProcess
8454 462 GetCurrentProcessId
846a 466 GetCurrentThreadId
8480 528 GetLastError
8490 627 GetStartupInfoA
84a2 650 GetSystemTimeAsFileTime
84bc 677 GetTickCount
84cc 761 InitializeCriticalSection
84e8 843 LeaveCriticalSection
8500 955 QueryPerformanceCounter
851a 1025 RtlAddFunctionTable
8530 1026 RtlCaptureContext
8544 1033 RtlLookupFunctionEntry
855e 1040 RtlVirtualUnwind
8572 1183 SetUnhandledExceptionFilter
8590 1196 Sleep
8598 1210 TerminateProcess
85ac 1217 TlsGetValue
85ba 1230 UnhandledExceptionFilter
85d6 1260 VirtualProtect
85e8 1262 VirtualQuery
00008014 00008110 00000000 00000000 000088f8 000082f0
DLL Name: msvcrt.dll
vma: Hint/Ord Member-Name Bound-To
85f8 55 __C_specific_handler
8610 78 __dllonexit
861e 81 __getmainargs
862e 82 __initenv
863a 83 __iob_func
8648 91 __lconv_init
8658 97 __set_app_type
866a 99 __setusermatherr
867e 115 _acmdln
8688 123 _amsg_exit
8696 141 _cexit
86a0 253 _fmode
86aa 330 _initterm
86b6 438 _lock
86be 610 _onexit
86c8 818 _unlock
86d2 1030 abort
86da 1044 calloc
86e4 1055 exit
86ec 1072 fprintf
86f6 1079 free
86fe 1090 fwrite
8708 1137 malloc
8712 1145 memcpy
871c 1174 signal
8726 1195 strlen
8730 1198 strncmp
873a 1229 vfprintf
00008028 000081f8 00000000 00000000 0000891c 000083d8
DLL Name: libstdc++-6.dll
vma: Hint/Ord Member-Name Bound-To
8748 1247 _ZNSolsEPFRSoS_E
875c 2938 _ZNSt8ios_base4InitC1Ev
8778 2940 _ZNSt8ios_base4InitD1Ev
8794 3195 _ZSt4cout
87a0 3196
_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
87e0 3269
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
0000803c 00000000 00000000 00000000 00000000 00000000
# what DLLs is the executable dependent upon?
C:\Users\Jon\Documents\CDev\sandbox>objdump -x hello.exe | grep "DLL Name"
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: libstdc++-6.dll
This can go on and on and on, and others likely have important newcomer
examples.
Good luck with spelunking the awesomeness that makes up your MinGW-w64
toolchain.
Jon
------------------------------------------------------------------------------
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
