Source for 'startup files' in gcc/mingw - c++

Im using mingw32
In gcc there is an option
" -nostartfiles Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib or -nodefaultlibs is used. "
If i do not use it in my itself almost empty c source i got in my exe 1000-lines disasembly long stub of code containing such functions
00401000 <___mingw_CRTStartup>:
00401110 <__gnu_exception_handler#4>:
00401280 <_mainCRTStartup>:
004012a0 <_WinMainCRTStartup>:
004012c0 <_atexit>:
004012d0 <__onexit>:
004012e0 <___gcc_register_frame>:
0040132c <___gcc_deregister_frame>:
00401334 <_WinMain#16>:
00401340 <___dyn_tls_dtor#12>:
00401390 <___dyn_tls_init#12>:
00401420 <___tlregdtor>:
00401430 <___cpu_features_init>:
00401510 <__fpreset>:
00401520 <___report_error>:
00401580 <___write_memory.part.0>:
00401690 <__pei386_runtime_relocator>:
00401870 <___do_global_dtors>:
004018a0 <___do_global_ctors>:
004018f0 <___main>:
00401910 <___mingwthr_run_key_dtors.part.0>:
00401970 <____w64_mingwthr_add_key_dtor>:
00401a00 <____w64_mingwthr_remove_key_dtor>:
00401a90 <___mingw_TLScallback>:
00401b30 <___getmainargs>:
00401b38 <__setmode>:
00401b40 <___p__fmode>:
00401b48 <___p__environ>:
00401b50 <__cexit>:
00401b58 <_signal>:
00401b60 <_fwrite>:
00401b68 <_vfprintf>:
00401b70 <_abort>:
00401b78 <_memcpy>:
00401b80 <_calloc>:
00401b88 <_free>:
00401b90 <_SetUnhandledExceptionFilter#4>:
00401b98 <_ExitProcess#4>:
00401ba0 <_GetModuleHandleA#4>:
00401ba8 <_GetProcAddress#8>:
00401bb0 <_VirtualQuery#12>:
00401bb8 <_VirtualProtect#16>:
00401bc0 <_GetCommandLineA#0>:
00401bc8 <_GetStartupInfoA#4>:
00401bd0 <_EnterCriticalSection#4>:
00401bd8 <_TlsGetValue#4>:
00401be0 <_GetLastError#0>:
00401be8 <_LeaveCriticalSection#4>:
00401bf0 <_DeleteCriticalSection#4>:
00401bf8 <_InitializeCriticalSection#4>:
00401c00 <_main>:
00401ce0 <_register_frame_ctor>:
00401cfc <__CTOR_LIST__>:
00401d00 <.ctors.65535>:
00401d08 <__DTOR_LIST__>:
Could maybe someone say where i could find source for that?
(or at least some detailed explanation what is that - but source would be better)

I guess you could download GCC sources or MinGW sources.
Since the mingw-w64 project on sourceforge.net is moving to mingw-w64.org I suggest also to check mingw-w64.org and then run grep or similar text search utility and find particular file(s) where those function(s) are defined.
Note also that some functions like exit(), atexit(), memcpy(), etc. are coming from C Run-Time Library, they won't be defined in GCC sources.

Related

`cabal repl` causes GHC panic on simple project with C++ files

I've uploaded the project as a zip file so you can try it out.
https://dl.dropboxusercontent.com/u/35032740/ShareX/2015/11/Buggy.zip
I wanted to write a wrapper around the clipper library. The code compiles fine with cabal build, runs with cabal run but cabal repl produces this error:
Preprocessing executable 'Buggy' for Buggy-0.1.0.0...
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
GHC runtime linker: fatal error: I found a duplicate definition for symbol
_ZNSt6vectorIN10ClipperLib8IntPointESaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_
whilst processing object file
dist\build\Buggy\Buggy-tmp\wrapper.o
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-mingw32):
loadObj "dist\\build\\Buggy\\Buggy-tmp\\wrapper.o": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
For reference, here's the cabal file
-- Initial Buggy.cabal generated by cabal init. For further documentation,
-- see http://haskell.org/cabal/users-guide/
name: Buggy
version: 0.1.0.0
-- synopsis:
-- description:
-- license:
license-file: LICENSE
author: Luka Horvat
maintainer: lukahorvat9#gmail.com
-- copyright:
-- category:
build-type: Simple
-- extra-source-files:
cabal-version: >=1.10
executable Buggy
main-is: Main.hs
c-sources: clipper.cpp
, wrapper.cpp
-- other-modules:
-- other-extensions:
build-depends: base >=4.8 && <4.9
-- hs-source-dirs:
default-language: Haskell2010
extra-libraries: stdc++
Any ideas what the cause might be here?
I'm running Windows 10, 64bit.
I don't know the details of object file formats on Windows, so I'm guessing a bit.
Probably clipper.o and wrapper.o both define a weak symbol named _ZNSt6vectorIN10ClipperLib8IntPointESaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_. (I see the same on Linux.) This probably came from a template instantiation (of vector). Weak symbols instruct the system linker to just pick any copy of the symbol if it encounters duplicates.
GHCi on Windows doesn't use the system linker, it has its own runtime linker that can load object files into itself while it runs. As a result it is generally not feature compatible with the system linker. Probably the runtime linker does not understand weak symbols, at least on Windows (https://ghc.haskell.org/trac/ghc/ticket/3333). From the error you got, we can assume that it treats them as regular symbols, and two regular symbols are not allowed to have the same name.
As a workaround, you may be able to build your C++ files with -fno-weak as described in https://stackoverflow.com/a/26454930/190376.
If that doesn't work, an alternative is to build your C++ files into a DLL, which you can have GHCi load using the system dynamic loader, avoiding this whole issue. On Linux this would look like
g++ wrapper.cpp clipper.cpp -shared -fPIC -o libclipper.so
ghci -L. -lclipper
though I imagine the details are different on Windows.
The specific error isn't what I'm used to seeing, but those backslashes say you're on Windows, and this otherwise looks like GHC bug #3242 which has been causing pain for years now. Good news: the cause was finally isolated two weeks ago. Bad news: the fix didn't make the deadline for 7.10.3, though at least the 8.0.1 milestone seems secure at this point.
Probably still worth posting your error text to that bug's thread; mine is only an educated guess, someone there will know for sure.

linker (ld) on OS X: How to use -Wl,--start-group (and --end-group)?

I am building some projects externally which use libclang static libs.
Linking fails like this:
ld: unknown option: --start-group
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The reason I need to use this is because of circular dependencies (or as it turns out, I guess because of not knowing the correct library order).
So far I have to resort to taking the -Wl,--{start,end}-group out of the makefile, looking at the undefined symbols error list, finding the libs that have them with nm, and appending them manually to the library list (so they appear more than once in the library list).
The correct order of LLVM/Clang libs (taken from my own project that uses it) for 3.5 is:
"clangFrontend",
"clangSerialization",
"clangDriver",
"clangTooling",
"clangCodeGen",
"clangParse",
"clangSema",
"clangAnalysis",
"clangRewriteFrontend",
"clangRewrite",
"clangEdit",
"clangAST",
"clangLex",
"clangBasic",
"LLVMLTO",
"LLVMObjCARCOpts",
"LLVMLinker",
"LLVMipo",
"LLVMVectorize",
"LLVMBitWriter",
"LLVMIRReader",
"LLVMAsmParser",
"LLVMR600CodeGen",
"LLVMR600Desc",
"LLVMR600Info",
"LLVMR600AsmPrinter",
"LLVMSystemZDisassembler",
"LLVMSystemZCodeGen",
"LLVMSystemZAsmParser",
"LLVMSystemZDesc",
"LLVMSystemZInfo",
"LLVMSystemZAsmPrinter",
"LLVMHexagonCodeGen",
"LLVMHexagonAsmPrinter",
"LLVMHexagonDesc",
"LLVMHexagonInfo",
"LLVMNVPTXCodeGen",
"LLVMNVPTXDesc",
"LLVMNVPTXInfo",
"LLVMNVPTXAsmPrinter",
"LLVMCppBackendCodeGen",
"LLVMCppBackendInfo",
"LLVMMSP430CodeGen",
"LLVMMSP430Desc",
"LLVMMSP430Info",
"LLVMMSP430AsmPrinter",
"LLVMXCoreDisassembler",
"LLVMXCoreCodeGen",
"LLVMXCoreDesc",
"LLVMXCoreInfo",
"LLVMXCoreAsmPrinter",
"LLVMMipsDisassembler",
"LLVMMipsCodeGen",
"LLVMMipsAsmParser",
"LLVMMipsDesc",
"LLVMMipsInfo",
"LLVMMipsAsmPrinter",
"LLVMAArch64Disassembler",
"LLVMAArch64CodeGen",
"LLVMAArch64AsmParser",
"LLVMAArch64Desc",
"LLVMAArch64Info",
"LLVMAArch64AsmPrinter",
"LLVMAArch64Utils",
"LLVMARMDisassembler",
"LLVMARMCodeGen",
"LLVMARMAsmParser",
"LLVMARMDesc",
"LLVMARMInfo",
"LLVMARMAsmPrinter",
"LLVMPowerPCDisassembler",
"LLVMPowerPCCodeGen",
"LLVMPowerPCAsmParser",
"LLVMPowerPCDesc",
"LLVMPowerPCInfo",
"LLVMPowerPCAsmPrinter",
"LLVMSparcDisassembler",
"LLVMSparcCodeGen",
"LLVMSparcAsmParser",
"LLVMSparcDesc",
"LLVMSparcInfo",
"LLVMSparcAsmPrinter",
"LLVMTableGen",
"LLVMDebugInfo",
"LLVMOption",
"LLVMX86Disassembler",
"LLVMX86AsmParser",
"LLVMX86CodeGen",
"LLVMSelectionDAG",
"LLVMAsmPrinter",
"LLVMX86Desc",
"LLVMX86Info",
"LLVMX86AsmPrinter",
"LLVMX86Utils",
"LLVMJIT",
"LLVMLineEditor",
"LLVMMCAnalysis",
"LLVMMCDisassembler",
"LLVMInstrumentation",
"LLVMInterpreter",
"LLVMCodeGen",
"LLVMScalarOpts",
"LLVMInstCombine",
"LLVMTransformUtils",
"LLVMipa",
"LLVMAnalysis",
"LLVMProfileData",
"LLVMMCJIT",
"LLVMTarget",
"LLVMRuntimeDyld",
"LLVMObject",
"LLVMMCParser",
"LLVMBitReader",
"LLVMExecutionEngine",
"LLVMMC",
"LLVMCore",
"LLVMSupport"
You don't have to determine the order yourself- use -llvm-config to get the LLVM order. The Clang order is a bit trickier- from memory, you need to extract it from makefiles used to build Clang itself, or something like that. However, the Clang list is pretty small so determining it is pretty easy given the LLVM order and that Clang must go before LLVM. I don't know where libclang goes in this list since I don't use it, but I'm guessing that it should go first.
The accepted answer by #Puppy does answer the OP's ultimate need -- how to get the libraries in required link order.
But it does not answer the OP's actual question -- how to use --start-group and --end-group.
The clang and gcc command line options are:
-Wl,--start-group
libs-in-the-order-you-need ...
-Wl,--end-group
Your mileage may vary on other compilers.
UPDATE (2019.07.11):
David Given points out that the gcc provided by default on OSX doesn't even support these options.
That is because OSX only provides gcc 2.x compatibility.
I was using gcc 4.8 and gcc 7.0 when I started using these options in my project.
I am not sure when they were first added to gcc.

Compiling DISLIN gfortran

I am having trouble compiling Fortran code with references to DISLIN. I have downloaded DISLIN from the website, unzipped the file and ran the setup. I have added an environment variable called DISLIN (C:\dislin) and added C:\dislin\win to the PATH section of my system variables.
I am trying to compile some example code of the DISLIN website which includes line
USE DISLIN
I am using a MinGW shell to compile with command gfortran -o progrname -ldislin EX11_1.f90 and am getting the following error:
Fatal Error: Cant open module file 'dislin.mod' for reading at (1): No such file or directory.
I have tried changing the variable path and even moving the dislin.mod file (which is there) but still get the same message.
Ok I fixed this problem so thought I come back and post what worked for me incase any one else needs it...
Install both DISLIN and MinGW on the c drive
Copy disgf.a from /c/dislin and dislin.f90 from /c/dislin/gf into the directory containing your fortran files
(for me this is /c/MinGW/pnote)
Using the MinGW shell navigate to you files: cd /c/MinGW/pnote
compile dislin.f90 and your fortran program: gfortran -c dislin.f90 progName.f90 (dislin.f90 obviously only needs to be done once)
link libraries etc and compile: gfortran progName.o disgf.a -luser32 -lgdi32 -lopengl32 -o exeName
'run' exeName
You probably need to specify the path to the DISLIN module files:
gfortran EX11_1.f90 -o progrname -ldislin -I/path/to/DISLIN/modules
and, if not already configured like described here, also the path to the library itself:
gfortran EX11_1.f90 -o progrname -ldislin -I/path/to/DISLIN/modules \
-L/path/to/DISLIN/library
They provide a batch file (windows) to do the compiling and linking for you.
f90link -c My_Program
This is located in c:\dislin\Win
Also, if you are having trouble with the dislin.mod file which resides in c:\dislin\gf then recompile that with the -c compile option. I found all of this info in c:\dislin\readme.inf
near as I can tell (Jan 2018) dislin (64 bit) fails miserably with gfortran 7.2, period; and probably with many other newer compilers.
When trying to link, gfortran 7 says 'dislin.mod' is an unrecognizable format.
I think this program is highly dependent on exactly correct version synchronization - something that renders such software useless imho after many years in research.
and no, the correctness of various 'paths' seems not to help.
after all, gnuplot works, "at all". Not sure why I spent so much time on brand x.
jrc

LLVM libc++ not compiling with clang 3.3 on Mac OS

I have just downloaded clang 3.3 (homebrew) from the LLVM web page to my mac (OS X 10.8.4), but get this compiler error when using std=c++11 stdlib=libc++:
In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:594:
In file included from /usr/include/c++/v1/memory:590:
In file included from /usr/include/c++/v1/typeinfo:61:
/usr/include/c++/v1/exception:146:5: error: an attribute list cannot appear here
_LIBCPP_NORETURN friend void rethrow_exception(exception_ptr);
^~~~~~~~~~~~~~~~
/usr/include/c++/v1/__config:190:28: note: expanded from macro '_LIBCPP_NORETURN'
# define _LIBCPP_NORETURN [[noreturn]]
^~~~~~~~~~~~
It seems that I also need another libc++ (even though it was said that it was 100% complete on MAC ...), but I cannot find any. Any help appreciated. Just for your info:
> clang++ -v
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
And, yes, I googled it and found this: http://comments.gmane.org/gmane.comp.compilers.llvm.bugs/24138 claiming it's resolved in libc++ trunk ???
Okay, as suggested by Howard, I've downloaded tip-of-the-trunk libc++ into /opt/local/share/libcxx, but have trouble building it. The manual says to cd libcxx/lib, export TRIPLE=-apple-, and run ./buildit. I presume this implies bash (I'm usually a tcsh user, so I moved my .tcshrc, got a new shell and started bash). I did that and the compilations worked, but the library build failed. Apparently ./buildit doesn't see $TRIPLE=-apple-, as it picks the wrong LDSHARED_FLAG (not that on line 81, but that on line 103, which is to be used if $TRIPLE is not set), even though echo $TRIPLE yields -apple- as it should. When I add the statement echo TRIPLE = $TRIPLE at the top of buildit, it reports nothing. How come? What is wrong here?
The failure was that because the wrong LDSHARED_FLAG was picked the loading didn't work (ld complaint about the unknown option -soname which, I think, makes sense under linux). I don't know why buildit (a #! /bin/sh file) didn't pick up the TRIPLE environment variable (it did pick up several unwanted ones such as CXX and CC). I now simply added TRIPLE=-apple- at the top of that file and it did built the library. However, the loader spitted out several warnings all of which were of the form
ld: warning: direct access in ___cxa_bad_typeid to global weak symbol typeinfo for std::bad_typeid means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
But most importantly, it works (the compilation at least, I have yet to test the library). I have one final question. The advice was to use -I and -L to tell the compiler about the whereabouts of this version. Is it not possible to put it into the usual place /usr/include/c++/v1/? Note that Xcode has its version somewhere else anyway and I had put in a symbolic link (/usr/include/c++/v1/) to that one to get my homebrew clang 3.2 working (after the some Xcode update). What about the library? Can I also put it in a standard place?
Here is the home page of libc++:
http://libcxx.llvm.org
You can download the tip-of-trunk libc++ from there. You can tell clang to point to your download with -nostdinc++ -I<path-to-libc++>/include. You can also tell clang to link to your tip-of-trunk libc++ with -L<path-to-libc++>/lib and export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib. The directions are all on the libc++ home page.
Xcode is the easiest way to get clang + libc++. But if you want the very latest, this is the place to go.
Congratulations!
Don't worry about the ld warning. It is a harmless ld bug that will be fixed in a future release. I see it on 10.8.4 too and it doesn't hurt anything.
The libc++ headers no longer live at /usr/include/c++/v1. Xcode has migrated them into itself. Having libc++ headers at /usr/include/c++/v1 from older installs has been a source of confusion and bugs. I regularly use -nostdinc++ -I to point to the libc++ headers I want (I often have several versions going at the same time), and that works well for me.
It is possible for you to replace your /usr/lib/libc++.1.dylib with that you have built. I do not recommend doing this. I have to sometimes to do a proper test, but I always do so very carefully because sometimes this causes me to have to reboot onto a backup disk and restore my /usr/lib to its original state. If you do go this route, it is a very good idea to have a backup of the original /usr/lib/libc++.1.dylib very handy.
I recommend instead -L on the command line, and export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib in the shell. More than one person (including myself) has gotten their computer into a really nasty place by not following this advice.
If you run testit (under test/), all you need is DYLD_LIBRARY_PATH in that shell. The testit script is set up to point to the right places without an install.
Also I recommend figuring out why you had to modify buildit. No one else is seeing that behavior. printenv on your command line may help in this endeavor.
libc++ is updated often. We try to keep tip-of-trunk always in a shippable state.

Win32 API stack walk with MinGW/MSYS?

i've to develop a stack trace walk to our win32 API plattform support to catch any exception with a behaviour of a JAVA stacktrace. Actually we got a full functional implementation for Linux plattforms.
First i've tried to implement a stackwalk using the win32 CaptureStackBackTrace API
mechanism. But this method is not integrated in the actually winbase header of mingw (using MSYS/MinGW 5.1.x) ...
So i decided tried use the dbgheader mechanism follwoing the instructions of this link :
http://sites.google.com/site/kenscode/prime-programs/boinc-with-mingw-on-win32
But i fail again and run into linker failures i could not solve. I think MinGW could not resolve the dbgheader library ....
DrMinGW is not an option for me, while it is a JIT Debugger, i've to implement a stack trace mechansim, for any exception occuring on runtime with a customizable log file tracebility like we know from JAVA ...
Has anyone get MSYS/MinGW runable with the win32 API in handshake? I will not change the compiler to the ugly MVC compiler instead of using MSYS/MinGW...
Thanks for any hint.
Best regards,
Christian
Check Mr. Edd's stack trace library at the following link. It will produce a nice stack frame listing and has specific code to support MinGW.
http://www.mr-edd.co.uk/code/stack_trace
His library uses dbghelp.dll, however, so you may get into some problems trying to compile it. As far as I know, MinGW doesn't include an import library for this DLL (see a old feature request here). I had success, however, creating one import library myself. You can do the same just using a .def file from the Wine project (check the previous link's attached files for one) and running the MingW utility dlltool:
dlltool -k -d dbghelp.def -l dbghelp.a
You can then include the resulting dbghelp.a file in your project. You won't probably like to have dependencies towards dbghelp.dll in your release builds, as the DLL itself is surely not redistributable.
Here is a method to walk the call stack using the Win32 API which you can call from MinGW.
http://www.codeproject.com/KB/threads/StackWalker.aspx
I got stack traces working in MingGW with Edd's dbg library, which is a successor to his minimal stack_trace library:
With msys2, this should get you a stack trace:
$ pacman -S mingw-w64-x86_64-edd-dbg
// main.cpp
#include <dbg/frames.hpp>
#include <dbg/symbols.hpp>
#include <iostream>
int main()
{
dbg::symdb db;
dbg::call_stack<64> traceback;
traceback.collect(0);
traceback.log(db, std::cout);
return 0;
}
$ g++ -ggdb main.cpp -ldbg
$ ./a.exe
0x0000000000402ee9: dbg::call_stack<64u>::collect(unsigned int) in C:\msys64\home\phil\stacktrace-example\a.exe
0x00000000004015f2: main in C:\msys64\home\phil\stacktrace-example\a.exe
0x00000000004013f8: __tmainCRTStartup in C:\msys64\home\phil\stacktrace-example\a.exe
0x000000000040151b: mainCRTStartup in C:\msys64\home\phil\stacktrace-example\a.exe
0x00007ffbb0838102: BaseThreadInitThunk in C:\WINDOWS\system32\KERNEL32.DLL
0x00007ffbb27cc5b4: RtlUserThreadStart in C:\WINDOWS\SYSTEM32\ntdll.dll
More about dbg can be found in the Wiki. The code is available here: https://bitbucket.org/edd/dbg/src