[Scons-users] Scons 2.3.2 regression for Dynamic library compilation

[Russel Winder]

Laurent,

On Fri, 2014-08-08 at 17:22 +0200, M. Laurent MARCHELLI wrote:
> Hello,
> 
> I work on a big project than compiled on Window 2007 without any major problem with the scons version 2.3.0.
> Since I have installed the version 2.3.2, all Dynamic Linked libraries didn't compiled anymore.

Clearly not an acceptable situation!

> I investigated the problem and the issue is located inside the new dmd implementation.

Curses, this is not good.

> Scons seems to get confused with .def files extensions. Instead than calling the 'LINK' program to create the DLL, it try to call the 'DLINK' program.
> However, I do not have installed any D language compiler on my system. 

This is weird. DLINK should only be used if you have .d source files in
the input list.

It seems that only the tools mingw and mslink deal with .def files, so
the error will only arise using one of them. I only use Linux, and do
some testing on OSX, it appears that no-one had tried things using mingw
or mslink before release. I am guessing the issue here is that somewhere
the existence of the .def input file is being caught as a .d file.

What is needed is a tiny little project that exhibits the problem for
you. This can then be added to the D test suite. This will then force a
solution to be executed.

> I compared scons environment variables between version 2.3.0 and 2.3.2 and I noticed that all 'D...' variables are now added whatever your system has or not any D compiler.
> To fix this I dug into the Scons source code to try to identify the trouble, and I was surprise to see the 'DLINK' is forced whatever his presence on the system.

It is certainly true that the D-related stuff was a breaking change for
D code builds 2.3.1 to 2.3.2 but it shouldn't have changed anything
non-D-related.

> I modified the code (see patch below in Unify diff) and the build is now successful.
> *************************************************************************************
> --- Tool\__init__.py.old	2014-07-05 09:42:26.000000000 +0200
> +++ Tool\__init__.py	2014-08-08 14:20:17.953394600 +0200
> @@ -799,7 +799,7 @@
>          ar = FindTool(ars, env) or ars[0]
>  
>      d_compilers = ['dmd', 'gdc', 'ldc']
> -    d_compiler = FindTool(d_compilers, env) or d_compilers[0]
> +    d_compiler = FindTool(d_compilers, env) 
>  
>      other_tools = FindAllTools(other_plat_tools + [
>                                 #TODO: merge 'install' into 'filesystem' and
> **************************************************************************************

I am not yet convinced this is the right thing to do, but I could be, so
I am definitely not ruling it out. The issue is whether d_compiler
should refer to None for systems without a D compiler present – if
indeed that is what FindTools returns as the "failed to find" value.

> So, I have two questions,
> - Is this modification correct for those who don't have any D compiler and will it be inserted in the next release ?

Not sure. What is needed is for someone with a Windows machine to work
with me on a feature clone repository of SCons (*) to ensure we get the
right solution for all situations.

> - What's happening if I install a D compiler on my system ? Why Scons tries to call the 'DLINK' instead of the 'LINK' program, is it a bad configuration between sources and targets ?

I have no idea! DMD is known to work fine on Windows, OSX and Linux. LDC
will almost certainly work on all platforms, but I am not sure about
GDC. I am very much an LDC user, with some use of LDC and occasional use
of DMD.

I think the bug is something to do with the .d confused by .def which is
related to the smart_linker code. If there is a bug here it most
definitely needs fixing.

What has me concerned just now is that your removal of 'or
d_compilers[0]' as noted above appears to fix the problem. I think this
is actually indicative of a third factor, the location of the actual
bug.

I think it would be good if you raise a formal "blocking" bug report on
Tigris, this will ensure a fix has to be in 2.3.3.


(*) I know there are supposed to be Mercurial mechanisms, MQ, bookmarks,
etc. but I am basically a Git person and I like my in-repository,
transient feature branches.
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://four.pairlist.net/pipermail/scons-users/attachments/20140809/b2bc97b9/attachment.pgp>