> >>> 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 ;) > > Did you try with `which gcc` and starting from there?
Yes, thanks. But I haven't spent enough time thinking about an easy way to use following to translate the `which gcc` path back to the cmd.exe friendly version...likely will settle on a (hopefully non-fragile) regex on the `sh -c "mount"` output. C:\Users\Jon\Documents>which gcc 'which' is not recognized as an internal or external command, operable program or batch file. C:\Users\Jon\Documents>sh -c "which gcc" /usr/mingw/bin/gcc C:\Users\Jon\Documents>sh -c "mount -l" /usr/bin/mount: /etc/fstab.conf: configuration file not found C:\Users\Jon\Documents>sh -c "mount" C:\Users\Jon\AppData\Local\Temp on /tmp type user (binmode,noumount) C:\DevKit-w64 on /usr type user (binmode,noumount) C:\DevKit-w64 on / type user (binmode,noumount) c: on /c type user (binmode,noumount) d: on /d type user (binmode,noumount) Jon --- blog: http://jonforums.github.com/ twitter: @jonforums Most people die of a sort of creeping common sense, and discover when it is too late that the only things one never regrets are one's mistakes. - Oscar Wilde ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
