static linking of dlls with bmk_ng?
BlitzMax Forums/Brucey's Modules/static linking of dlls with bmk_ng?
| ||
| Hi, There are two dlls that are needed by my application in the MinGW dir: "~MinGW/bin/libstdc++-6.dll" and "~MinGW/bin/libgcc_s_sjlj-1.dll" I want to statically link them in the exe. How to do that? BMK_NG comes with a "custom.bmk" file in which I can add compiler setting (I think). But "addwin32ccopt -static-libstdc++" or "addwin32ccopt -lstdc++" made no difference. I will just add the dlls to the exe dir if there is no other solution. thx |
| ||
| It's linker option, not a compiler directive. I've just committed my latest work on bmk_ng, which happens to also include support for things like addwin32ldopt. According to information I found you want to use -static-libgcc and -static-libstdc++ I haven't tested it myself yet though, so good luck ;-) Latest bmk_ng also supports pre-build scripts (pre.bmk), and my initial work on automating sandboxing for OS X builds. (although given the interest in the other thread, I'm probably the only one interested in that. I guess everyone else is using Monkey these days for their OS X development :-p ) |
| ||
| I get an error with the new bmk_ng: the code SuperStrict Framework brl.standardio DebugLog "hello world!" throws g++: error: unrecognized command line option '--stack=4194304' g++: error: unrecognized command line option '--subsystem,windows' BTW: Should one recompile all modules with a new bmk_ng? |
| ||
| And that's what happens when I commit stuff 'early'. I've now tested it on win32, and fixed an issue with getting the gcc version number. Still haven't had time to test the ldopts stuff... Should one recompile all modules with a new bmk_ng? I don't think it's necessary in this case. The ld options should only affect the final binary build, and not the modules. |
| ||
| bmk_ng works now. adding "addwin32ldopt -static-libgcc -static-libstdc++" to custom.bmk changes nothing though. I think I will just add the dlls to the release. Doesn't make a difference really, does it? |
| ||
| Hello, statically linking libstdc++ should be ok, but statically linking libgcc might be problematic as mentioned here -Henri |
| ||
| What version of MinGW are you using? I use TDM, and it apparently statically links stdc++ automatically. |
| ||
| Anyway, I've committed another update, which actually now uses user-defined ld opts on win32... For program specific linking, you probably don't want to put anything in custom.bmk. Rather use the application itself : SuperStrict ' @bmk addldopt static_stdc -static-libstdc++ ' @bmk addldopt static_gcc -static-libgcc Framework brl.standardio Print "hello world!" Those particular options don't work in TDM 4.7 ... FYI |
| ||
| my MinGW is TDM 4.7.1 You should update the readme.txt or something with the new functionality SuperStrict ' @bmk addldopt static_stdc -static-libstdc++ ' @bmk addldopt static_gcc -static-libgcc Framework brl.standardio Print "hello world!" nice! :) But I think I add the dlls to the download anyway. EDIT: got a new issue: when you do "bmk.exe makemods brl" all modules are build instead the brl modules. |
| ||
| @MinGW: I think brucey should have known that you are with 4.7.1 - the version he uses - and therefor this version is the one wxmax ist tested with. Just a bad thing maxmod2 has some troubles with 4.7.1 and relies on 4.6.x. @UNZ If you intend to provide "patches" for the app you better leave the dlls extra so you could skip providing them in patch files. bye Ron |
| ||
| I think brucey should have known that you are with 4.7.1 Yes, I realised that afterwards when I remembered what project he was working on. |
| ||
| all modules are build instead the brl modules. So it would seem. I'm working on a "fix", but the internals of bmk are a bit convoluted. ;-) |
   |