From: JonY <jo...@us...> - 2011-09-20 22:45:33
|
On 9/21/2011 00:19, Jon wrote: >>> I'm working on an app (targeted to run on WinXP_SP2+) having DLLs with runtime dependencies on the particular MinGW-w64 `libgcc_s_sjlj-1.dll` and `libstdc++-6.dll` artifacts used to build the app. As such, these specific artifact versions will need to be placed on the end users PATH. >>> >>> I'm interested in hearing whether others have discovered particularly clever examples of automating a build process to ensure the build's install/archive step includes the correct versions of these MinGW-w64 toolchain artifacts. >> >> Why not just bundle the DLLs along side the user executable? > > Yes, that's the current plan. > > I'm looking for a way to automate the build to copy those deps alongside the user executable without needing new env vars or hardcoded paths that make the build too tweaky. > > For example, let's say I build by pulling the MinGW-w64 toolchain and friends onto PATH like > > PATH=C:\Devkit-w64\bin;C:\Devkit-w64\mingw\bin;... > > in which MSYS and others live in C:\Devkit-w64\bin and key MinGW-w64 artifacts live in C:\Devkit-w64\mingw\bin. > > I'd like the build process (non-make running on Windows) to be able to reach into C:\Devkit-w64\mingw\bin (in this specific case, not generally) and copy dep DLLs as part of an install/package step by cajoling gcc (or something else in MinGW-w64) into telling me where it's running from (e.g. - `gcc -print-search-dirs`), easily parsing it's output, and building up the DLL paths for use by `cp`. > > I was hoping someone may have come across a clever solution to something similar. Or an easier way of looking at it ;) > > Jon > Did you try with `which gcc` and starting from there? |