[Scons-users] Problem with DLL dependencies on Windows

[Kenny, Jason L]

I believe the mingw tool should be ok. I think I calling in my extension Parts to get mingw support ( as Parts adds basic gcc version section and better cross compiler support).

The items I believe you will want to check are:
1) make sure the .a you want to link with is in the libpath. The Program scanner ( ie used for DLL and programs) in SCons will try use the value to find any .a files that you need to link with in the program. If it does not find it, scons such ignore the lib file and not setup the correct dependency.
2) make sure the that the LIBSUFFIXES variable has the correct values in the list. Ideally it should have .a and .lib ( just be safe)

Given these items are setup correctly I believe SCons should be working correctly. You can see what Scons is thinking here ( ie did it see the items and find the stuff on the path) via adding a --debug=findlibs

Hope this helps,
Jason

-----Original Message-----
From: scons-users-bounces at scons.org [mailto:scons-users-bounces at scons.org] On Behalf Of Dmitry Mikhin
Sent: Friday, May 24, 2013 8:36 AM
To: SCons users mailing list
Subject: Re: [Scons-users] Problem with DLL dependencies on Windows

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

>

_______________________________________________
Scons-users mailing list
Scons-users at scons.org
http://four.pairlist.net/mailman/listinfo/scons-users