2013/7/15 Jon <[email protected]>: > On Mon, 15 Jul 2013 11:02:20 +0400 > niXman <[email protected]> wrote: > >> 2013/7/15 Jon: >> > When I build C apps with mingwbuilds 4.8.1-win32-sjlj, the built artifacts >> > have a runtime dependency on >> > `libgcc_s_sjlj-1.dll`. This is not the case when I use the rubenvb >> > toolchains. >> >> Just now I checked with [1] and [2] and found no dependency on >> `libgcc_s_sjlj-1.dll` >> What am I doing wrong? >> >> >> [1] >> http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/64-bit/threads-win32/sjlj/x64-4.8.1-release-win32-sjlj-rev2.7z >> [2] >> http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/64-bit/threads-win32/sjlj/x64-4.8.1-release-win32-sjlj-rev1.7z > > Sorry, I wasn't clear. It seems that only the built DLLs (not exes) have a > dependency on `libgcc_s_sjlj-1.dll` when I build with [1] but not [2]. For > example, the DLLs built for both Lua and UnQLite (and Ruby using different > build helper) using these build recipes: > > Lua: > https://github.com/jonforums/buildlets/blob/master/build_lua.ps1#L60-L72 > UnQLite: > https://github.com/jonforums/buildlets/blob/master/build_unqlite.ps1#L60-L72 > > When I use PEStudio [3] v7.19 for static analysis, I see the DLLs are trying > to import the following symbols from `libgcc_s_sjlj-1.dll`: > > ** unqlite.dll ** > __divdi3 > __moddi3 > __udivdi3 > __umoddi3 > > ** lua52.dll ** > __udivdi3 > __umoddi3 > > I'm still investigating to try to discover if I've misconfigured my automated > build helpers. >
This issue is related to all gcc-4.8.x toolchains. All pre gcc-4.8 toolchains work ok. I have this issue too but in other form. My issue is related to use gcc-4.8.x toolchain for building other toolchain with the same symptoms. For example, I need to build GCC-4.8.1 toolchain with dwarf exceptions. I have GCC-4.8.1 toolchain with sjlj exceptions. After building new toolchain I have liblto_plugin-0.dll depended on old GCC libgcc_s_sjlj-1.dll. On dependency walker I see it want __udivdi3 and __umoddi3 functions from this dll. I have this issue only when building any toolchain with gcc-4.8.x. If I use earlier gcc versions (<=4.7.3) then new liblto_plugin-0.dll doesn't depend on any toolchain dll - only system wide libraries. Regards, Alexey. > Jon > > > [1] > http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/32-bit/threads-win32/sjlj/x32-4.8.1-release-win32-sjlj-rev2.7z > [2] > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.7-release/i686-w64-mingw32-gcc-4.7.4-release-win32_rubenvb.7z > [3] http://www.winitor.com/ > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Mingw-w64-public mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
