[Scons-users] Problem with DLL dependencies on Windows

Dmitry Mikhin dmitry.mikhin at gmail.com
Fri May 24 09:35:53 EDT 2013


I do not have MS tools installed, so, simply do not know. Somewhat
cursory inspection of mingw.py does not suggest it applies some
special activity regarding dlls when linking. (All references to dll
are in shared lib builders.)

So, likely you're correct. Next question is how to fix it :)
Dmitry

On Fri, May 24, 2013 at 10:55 PM, Gary Oberbrunner
<garyo at oberbrunner.com> wrote:

> This works OK with regular Windows compiler, right? Just not with mingw?

> Sounds like it could just be a problem with the mingw tool - for instance,

> maybe in the exe builder it's not searching for .dlls when looking for -l

> libs.

>

>

> On Fri, May 24, 2013 at 8:30 AM, Dmitry Mikhin <dmitry.mikhin at gmail.com>

> wrote:

>>

>> Hi Dan and everyone,

>>

>> Yes, this sounds similar indeed. Manual tracking of dependencies

>> (along the lines given in your email) would work, although IMO this

>> would be a kludge. It seems that SCons shall handle this automatically

>> (after all, even if I never mentioned the extension ".dll" in my

>> SConscripts, SCons somehow knows about it behind the scenes). SCons

>> knows about the dependency on ".a" files, can find the ".a" files in

>> the installed directory, and installs only the correct sub-set for

>> partial builds. Yet it skips DLLs, even if the obtained ".exe" clearly

>> depends on them.

>>

>> Seems like an extension is needed (do not want to call it "bug").

>> Dmitry

>>

>> On Fri, May 24, 2013 at 8:35 PM, Dan Pidcock <dan.pidcock at googlemail.com>

>> wrote:

>> > On 24 May 2013 09:41, Dmitry Mikhin <dmitry.mikhin at gmail.com> wrote:

>> >>

>> >> Yes, they do:

>> >> My targets: ['utils.dll', 'libutils.a']

>> >>

>> >> Any other ideas?

>> >> Dmitry

>> >

>> >

>> > I saw what may be a similar issue when using windows shared libraries.

>> > We

>> > have set scons up with variant directories (which are named for each

>> > library

>> > to prevent name clashes) which is where it creates the .dlls and .lib

>> > files.

>> > An Install builder is used to copy the .dll and .lib files over to a

>> > shared

>> > binary directory (one for each variant).

>> >

>> > When used with just scons on the command line this was OK, but when I

>> > build

>> > particular targets it didn't always update so I have a dictionary of the

>> > installed libraries which is keyed on each project, and then those are

>> > manually added to the dependency graph with Depends. Not sure if this is

>> > exactly the same scenario you have but maybe this will give you some

>> > ideas?

>> >

>> > We use something like:

>> > projectTarget = projectEnv.SharedLibrary(libraryName, Glob('*.cpp'))

>> > installedProject = projectEnv.Install(paths.BinPath(), projectTarget)

>> > installedLibraries[libraryName] = installedProject

>> >

>> > ... later ...

>> > (given a list requiredLibraries of libraries that a program depends on)

>> >

>> > for lib in requiredLibraries:

>> > if lib in installedLibraries:

>> > Depends(projectTarget, installedLibraries[lib])

>> >

>> > Dan

>> >

>> >

>> > _______________________________________________

>> > Scons-users mailing list

>> > Scons-users at scons.org

>> > http://four.pairlist.net/mailman/listinfo/scons-users

>> >

>> _______________________________________________

>> Scons-users mailing list

>> Scons-users at scons.org

>> http://four.pairlist.net/mailman/listinfo/scons-users

>

>

>

>

> --

> Gary

>

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users

>



More information about the Scons-users mailing list