[Scons-dev] [Scons-users] SharedLibrary + SHLIBVERSION and cygwin
William Blevins
wblevins001 at gmail.com
Sun Aug 30 12:40:00 EDT 2015
Did you try the patch as a short term solution?
On Aug 30, 2015 10:15 AM, "Paweł Tomulik" <ptomulik at meil.pw.edu.pl> wrote:
> William,
>
> please see comments below
>
>
> W dniu 28.08.2015 o 21:31, William Blevins pisze:
> >
> >
> > On Fri, Aug 28, 2015 at 12:32 PM, William Blevins <wblevins001 at gmail.com
> > <mailto:wblevins001 at gmail.com>> wrote:
> >
> > I have isolated the issue to the following commit:
> >
> https://bitbucket.org/scons/scons/commits/b347ff6e96d23d13298160e1e1e2f23a14c12460
> >
> > I can make a 1-line change to resolve the issue, but after skimming
> > the version shared library code, I think it need a legit refactor.
> > It hurts.
> >
> > Would it make more sense to set the shared library's name correctly
> > when the File is created, and remove the shlibname/shlibpath
> > attributes? It may be easier to address the actual problem rather
> > than skirt around it later? because the development (*.so) symlink
> > should not be the target output.
> >
> >
> > Seems like the SharedLibrary builder should take a target_factory, such
> > that, the output target is in the format libXXX.so.VERSION rather than
> > returning the symlink and "mucking" with the object. This way the
> > dependency graph will be correct in structure and all the symlinks can
> > be configured as SideEffects. I know very little about Builder
> > parameters and how _arg2node works though, so maybe someone can chime in
> > and confirm my suspicion?
> >
>
> t = env.SharedLibrary('foo', 'foo.c', SHLIBVERSION = '0.1.2')
> print "t[0]: ", str(t[0])
>
> This prints:
>
> t[0]: libfoo.so.0.1.2
>
> so the output target actually is the libXXX.so.VERSION library, not a
> symlink, which is fine, I think. Same way, the VersionedSharedLibrary
> already receives libXXX.so.VERSION as target[0]. The VERSION suffix is
> appended in shlib_emitter() functions (linkers).
>
> I suspect, that it's a problem with scanner which can't find the shared
> library libfooXXX.so.VERSION that would match -lfoo.
>
>
> Also, it looks like there are more issues. Just looking at the source of
> VersionedSharedLibrary() a couple of thoughts appeared:
>
> 1. There are shlink_flags which are appended to SHLINKFLAGS for
> versioned libraries. The choice of extra flags depends on the current
> PLATFORM. The flags, however, are passed to toolchains, not to
> "platforms". Platforms may support multiple toolchains, each having its
> own linker and linker-specific flags that should be applied
> when building versioned libraries.
>
> 2. Some of the extra SHLINKFLAGS are hard-coded. There is a post about
> this:
> http://comments.gmane.org/gmane.comp.programming.tools.scons.user/26311.
> This is a problem for some projects.
>
> 3. The code which determines symlink names is buggy -- see the attached
> example shlib-test-1.tar.gz. The example contains in essence the
> following SConstruct file:
>
> env = Environment()
> env.SharedLibrary('libfoo.so.0.1.2.d/foo', 'libfoo.so.0.1.2.d/foo.c',
> SHLIBVERSION = '0.1.2')
>
> The output with Verbose=True is:
>
> ptomulik at barakus:$ scons
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> gcc -o foo.os -c -fPIC foo.c
> VersionShLib: libname = libfoo.so.0.1.2
> VersionShLib: platform = posix
> VersionShLib: shlib_suffix = .so
> VersionShLib: target = blah.so.0.1.2.blah/libfoo.so.0.1.2
> soname libfoo.so.0 , shlink_flags -shared -Wl,-Bsymbolic
> -Wl,-soname=libfoo.so.0
> VersionShLib: shlink_flags = -shared -Wl,-Bsymbolic -Wl,-soname=libfoo.so.0
> gcc -o blah.so.0.1.2.blah/libfoo.so.0.1.2 -shared -Wl,-Bsymbolic
> -Wl,-soname=libfoo.so.0 foo.os
> VerShLib: target lib is = blah.so.0.1.2.blah/libfoo.so.0.1.2
> VerShLib: name is = libfoo.so.0.1.2
> VerShLib: dir is = blah.so.0.1.2.blah
> VerShLib: linknames ['blah.so.blah/libfoo.so', 'blah.so.blah/libfoo.so.0']
> scons: *** [blah.so.0.1.2.blah/libfoo.so.0.1.2] No such file or directory
> scons: building terminated because of errors.
>
>
> Note that it partially works if I set SHLIBVERSION=0.1.3 for example.
>
>
> 4. If SHLIBVERSION is used, the function clones the environment with
> env.Clone(). I believe, that the Override() could work here with less
> overheat. There is also another proposition (see 5.).
>
> 5. I think, that instead of modifying directly the SHLINKFLAGS in
> VersionedSharedLibrary() and using cloned environment, it's the
> SHLINKCOM which could be augmented to take into account some extra
> construction variables into account (specific to library versioning).
> With the help of sobstitution engine it could recognize the current
> platform/toolchain and generate the extra flags more reliably. As a
> benefit - all the settings, that are currently hard-coded, could be made
> user-configurable.
>
>
> >
> >
> > V/R,
> > William
> >
> >
> > On Fri, Aug 28, 2015 at 11:55 AM, William Blevins
> > <wblevins001 at gmail.com <mailto:wblevins001 at gmail.com>> wrote:
> >
> > I believe this is the same issue as
> >
> http://article.gmane.org/gmane.comp.programming.tools.scons.user/27049
> > which you already reported.
> >
> > The developer of the originating commit has not responded to me
> > yet, but it should be fixable. Try this for now...
> >
> > diff -r c2575505514f src/engine/SCons/Tool/link.py
> > --- a/src/engine/SCons/Tool/link.py Fri Aug 07 10:29:05 2015
> > -0400
> > +++ b/src/engine/SCons/Tool/link.py Fri Aug 07 13:30:28 2015
> > -0400
> > @@ -93,6 +93,7 @@
> > if Verbose:
> > print "shlib_emitter: add side effect -
> ",name
> > env.Clean(shlib, target[0])
> > + env.Depends(target[0], shlib)
> > return ([shlib], source)
> > except KeyError:
> > version = None
>
>
>
>
> The patch you've proposed doesn't fix the issue reported previously
> (http://article.gmane.org/gmane.comp.programming.tools.scons.user/27049).
> The expected application dependency on the library is still missing if
> -j 2 is used (see attached shlibversion-test.tar.gz):
>
> ptomulik at barakus:$ scons --tree=all -j2
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> g++ -o foo.os -c -fPIC -I. foo.cpp
> g++ -o main.o -c -I. main.cpp
> g++ -o main main.o -L. -lfoo
> g++ -o libfoo.so.0.1.2 -shared -Wl,-Bsymbolic -Wl,-soname=libfoo.so.0
> foo.os -L.
> /usr/bin/ld: cannot find -lfoo
> collect2: error: ld returned 1 exit status
> scons: *** [main] Error 1
> +-.
> +-SConstruct
> +-foo.cpp
> +-foo.hpp
> +-foo.os
> | +-foo.cpp
> | +-/usr/bin/g++
> +-libfoo.so
> | +-libfoo.so.0.1.2
> | +-foo.os
> | +-foo.cpp
> | +-/usr/bin/g++
> +-libfoo.so.0
> | +-libfoo.so.0.1.2
> | +-foo.os
> | +-foo.cpp
> | +-/usr/bin/g++
> +-libfoo.so.0.1
> | +-libfoo.so.0.1.2
> | +-foo.os
> | +-foo.cpp
> | +-/usr/bin/g++
> +-libfoo.so.0.1.2
> | +-foo.os
> | +-foo.cpp
> | +-/usr/bin/g++
> +-main
> | +-main.o
> | | +-main.cpp
> | | +-foo.hpp
> | | +-/usr/bin/g++
> | +-/usr/bin/g++
> +-main.cpp
> +-main.o
> +-main.cpp
> +-foo.hpp
> +-/usr/bin/g++
> scons: building terminated because of errors.
>
>
> I afraid, similar issue may be present in projects with SConscripts
> distributed among directories, even if -j is not used.
>
>
> Note, that the dependency is added when using single job:
>
>
> ptomulik at barakus:$ scons --tree=all
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> g++ -o foo.os -c -fPIC -I. foo.cpp
> g++ -o libfoo.so.0.1.2 -shared -Wl,-Bsymbolic -Wl,-soname=libfoo.so.0
> foo.os -L.
> g++ -o main.o -c -I. main.cpp
> g++ -o main main.o -L. -lfoo
> +-.
> +-SConstruct
> +-foo.cpp
> +-foo.hpp
> +-foo.os
> | +-foo.cpp
> | +-/usr/bin/g++
> +-libfoo.so
> | +-libfoo.so.0.1.2
> | +-foo.os
> | +-foo.cpp
> | +-/usr/bin/g++
> +-libfoo.so.0
> | +-libfoo.so.0.1.2
> | +-foo.os
> | +-foo.cpp
> | +-/usr/bin/g++
> +-libfoo.so.0.1
> | +-libfoo.so.0.1.2
> | +-foo.os
> | +-foo.cpp
> | +-/usr/bin/g++
> +-libfoo.so.0.1.2
> | +-foo.os
> | +-foo.cpp
> | +-/usr/bin/g++
> +-main
> | +-main.o
> | | +-main.cpp
> | | +-foo.hpp
> | | +-/usr/bin/g++
> | +-/usr/bin/g++
> | +-libfoo.so
> | +-libfoo.so.0.1.2
> | +-foo.os
> | +-foo.cpp
> | +-/usr/bin/g++
> +-main.cpp
> +-main.o
> +-main.cpp
> +-foo.hpp
> +-/usr/bin/g++
> scons: done building targets.
>
>
>
> >
> >
> > On Fri, Aug 28, 2015 at 7:56 AM, Paweł Tomulik
> > <ptomulik at meil.pw.edu.pl <mailto:ptomulik at meil.pw.edu.pl>>
> wrote:
> >
> > Hi, any ideas here?
> >
> > W dniu 2015-08-18 23:11, Paweł Tomulik pisze:
> >
> > No, it doesn't seem to help:
> >
> >
> > ptomulik at mwnotebook:$ scons --tree=all
> > scons: Reading SConscript files ...
> > scons: done reading SConscript files.
> > scons: Building targets ...
> > g++ -o foo.os -c -I. foo.cpp
> > g++ -o cygfoo-0-1-2.dll -Wl,-no-undefined -shared
> > -Wl,-Bsymbolic
> > -Wl,--out-implib,cygfoo-0-1-2.a
> > -Wl,--out-implib=libfoo-0-1-2.dll.a
> > -Wl,--export-all-symbols -Wl,--enable-auto-import
> > -Wl,--whole-archive
> > foo.os -Wl,--no-whole-archive -L.
> > g++ -o main.o -c -I. main.cpp
> > g++ -o main.exe -Wl,-no-undefined main.o -L. -lfoo
> > /bin/ld: cannot find -lfoo
> > collect2: error: ld returned 1 exit status
> > scons: *** [main.exe] Error 1
> > +-.
> > +-cygfoo-0-1-2.dll
> > | +-foo.os
> > | +-foo.cpp
> > | +-/bin/g++
> > +-cygfoo.dll
> > +-foo.cpp
> > +-foo.hpp
> > +-foo.os
> > | +-foo.cpp
> > | +-/bin/g++
> > +-libfoo-0-1-2.dll.a
> > | +-foo.os
> > | +-foo.cpp
> > | +-/bin/g++
> > +-main.cpp
> > +-main.exe
> > | +-main.o
> > | | +-main.cpp
> > | | +-foo.hpp
> > | | +-/bin/g++
> > | +-/bin/g++
> > +-main.o
> > | +-main.cpp
> > | +-foo.hpp
> > | +-/bin/g++
> > +-SConstruct
> > scons: building terminated because of errors.
> >
> >
> > After a single scons pass I see the following files in
> tree:
> >
> > ptomulik at mwnotebook:$ ls -lah
> > razem 28K
> > drwxr-xr-x+ 1 ptomulik Brak 0 08-18 22:34 .
> > drwxrwxrwt 1 ptomulik root 0 08-18 22:34 ..
> > -rw-r--r-- 1 ptomulik Brak 9,7K 08-18 22:34
> > .sconsign.dblite
> > lrwxrwxrwx 1 ptomulik Brak 18 08-18 22:34
> > cygfoo-0-1-2.dll ->
> > cygfoo-0-1-2.dll.0
> > lrwxrwxrwx 1 ptomulik Brak 16 08-18 22:34
> > cygfoo-0-1-2.dll.0 ->
> > cygfoo-0-1-2.dll
> > -rw-r--r-- 1 ptomulik Brak 25 08-10 11:12 foo.cpp
> > -rw-r--r-- 1 ptomulik Brak 50 08-10 11:12 foo.hpp
> > -rw-r--r-- 1 ptomulik Brak 616 08-18 22:34 foo.os
> > -rw-r--r-- 1 ptomulik Brak 2,8K 08-18 22:34
> > libfoo-0-1-2.dll.a
> > -rw-r--r-- 1 ptomulik Brak 48 08-10 11:14 main.cpp
> > -rw-r--r-- 1 ptomulik Brak 680 08-18 22:34 main.o
> > -rw-r--r-- 1 ptomulik Brak 1,3K 08-10 11:37 README.txt
> > -rw-r--r-- 1 ptomulik Brak 242 08-10 11:51 SConstruct
> >
> > Instead of the shared library cygfoo-*.dll I've got two
> > symlinks with a
> > circular dependency. I'm newbie here, but taking a look
> > into my /usr/lib
> > I can't see much "versioned names" with symlinks that
> > would resemble the
> > usual Linux way of shlib versioning. Quite better under
> > /usr/bin/ where
> > cygwin stored cyg*.dll stuff, but there is still quite
> > small number of
> > such symlinks. Has anyone checked whet is the standard
> > way of
> > implementing versioned libraries on cygwin (if there is
> > any)? Do you
> > know any docs, which describe it?
> >
> > Anyway, with unmodified SCons source, I let myself to
> > perform two simple
> > experiments. First, I've ran scons once (which failed),
> > then created the
> > following symlink
> >
> > ln -s libfoo-0-1-2.dll.a libfoo.dll.a
> >
> > and ran scons again - the mini-project was built
> > successfully now.
> >
> > Second experiment was similar, just with:
> >
> > ln -s cygfoo-0-1-2.dll cygfoo.dll
> >
> > and it let me build the project as well.
> >
> > The difference between the two was that in the second
> > case, scons -c
> > cleaned up the symbolic link cygfoo.dll, whereas in the
> > first case the
> > link libfoo.dll.a was not cleaned up.
> >
> >
> >
> > W dniu 2015-08-18 17:31, Bill Deegan pisze:
> >
> > Try changing line 259 of SCons/Tool/__init__.py from:
> >
> > elif platform == 'posix' or platform == 'sunos':
> >
> > to
> > elif platform == 'posix' or platform == 'sunos'
> > or platform ==
> > 'cygwin':
> >
> > And see if that fixes it.
> >
> > -Bill
> >
> >
> > On Tue, Aug 18, 2015 at 10:23 AM, Paweł Tomulik
> > <ptomulik at meil.pw.edu.pl
> > <mailto:ptomulik at meil.pw.edu.pl>
> > <mailto:ptomulik at meil.pw.edu.pl
> > <mailto:ptomulik at meil.pw.edu.pl>>> wrote:
> >
> > I'm not sure,
> >
> > AFAIR I only use packages installed via cygwin's
> > "setup.exe"
> > utility. I'm not 100% concious of how that stuff
> > works...
> >
> >
> > On 2015-08-18 15:57, Bill Deegan wrote:
> >
> > Looks like you are using the mingw tools and
> > not native cygwin
> > compiler?
> >
> > -Bill
> >
> > On Tue, Aug 18, 2015 at 8:58 AM, Paweł
> Tomulik
> > <ptomulik at meil.pw.edu.pl
> > <mailto:ptomulik at meil.pw.edu.pl>
> > <mailto:ptomulik at meil.pw.edu.pl
> > <mailto:ptomulik at meil.pw.edu.pl>>> wrote:
> >
> > Hi all,
> >
> > I just started experimenting with SCons
> > on cygwing trying to
> > port
> > one of my projects to cygwin. Looks like
> > I'm unlucky with the
> > SharedLibrary builder or just
> > misunderstand how stuff works.
> >
> > At the moment I'm trying to build a
> > minimal project with one
> > executable and one shared library. The
> > following is build
> > report
> > from that simple project (attached) on
> > cygwin, SCons 2.3.4,
> > python
> > 2.7.10:
> >
> > ptomulik at mwnotebook:$ scons --tree=all
> > scons: Reading SConscript files ...
> > scons: done reading SConscript files.
> > scons: Building targets ...
> > g++ -o cygfoo-0-1-2.dll
> > -Wl,-no-undefined -shared
> > -Wl,-Bsymbolic
> > -Wl,--out-implib,cygfoo-0-1-2.a
> > -Wl,--out-implib=libfoo-0-1-2.dll.a
> > -Wl,--export-all-symbols
> > -Wl,--enable-auto-import
> > -Wl,--whole-archive foo.os
> > -Wl,--no-whole-archive -L.
> > g++ -o main.exe -Wl,-no-undefined main.o
> > -L. -lfoo
> > /bin/ld: cannot find -lfoo
> > collect2: error: ld returned 1 exit
> status
> > scons: *** [main.exe] Error 1
> > +-.
> > +-cygfoo-0-1-2.dll
> > | +-cygfoo-0-1-2.dll
> > | +-foo.os
> > | +-foo.cpp
> > | +-/bin/g++
> > +-cygfoo-0-1-2.dll
> > | +-foo.os
> > | +-foo.cpp
> > | +-/bin/g++
> > +-foo.cpp
> > +-foo.hpp
> > +-foo.os
> > | +-foo.cpp
> > | +-/bin/g++
> > +-libfoo-0-1-2.dll.a
> > | +-foo.os
> > | +-foo.cpp
> > | +-/bin/g++
> > +-main.cpp
> > +-main.exe
> > | +-main.o
> > | | +-main.cpp
> > | | +-foo.hpp
> > | | +-/bin/g++
> > | +-/bin/g++
> > | +-cygfoo-0-1-2.dll
> > | +-foo.os
> > | +-foo.cpp
> > | +-/bin/g++
> > +-main.o
> > | +-main.cpp
> > | +-foo.hpp
> > | +-/bin/g++
> > +-SConstruct
> > scons: building terminated because of
> > errors.
> >
> > This is for SCons 2.3.5:
> >
> > ptomulik at mwnotebook:$ scons --tree=all
> > scons: Reading SConscript files ...
> > scons: done reading SConscript files.
> > scons: Building targets ...
> > g++ -o foo.os -c -I. foo.cpp
> > g++ -o cygfoo-0-1-2.dll
> > -Wl,-no-undefined -shared
> > -Wl,-Bsymbolic
> > -Wl,--out-implib,cygfoo-0-1-2.a
> > -Wl,--out-implib=libfoo-0-1-2.dll.a
> > -Wl,--export-all-symbols
> > -Wl,--enable-auto-import
> > -Wl,--whole-archive foo.os
> > -Wl,--no-whole-archive -L.
> > g++ -o main.o -c -I. main.cpp
> > g++ -o main.exe -Wl,-no-undefined main.o
> > -L. -lfoo
> > /bin/ld: cannot find -lfoo
> > collect2: error: ld returned 1 exit
> status
> > scons: *** [main.exe] Error 1
> > +-.
> > +-cygfoo-0-1-2.dll
> > | +-foo.os
> > | +-foo.cpp
> > | +-/bin/g++
> > +-cygfoo.dll
> > +-foo.cpp
> > +-foo.hpp
> > +-foo.os
> > | +-foo.cpp
> > | +-/bin/g++
> > +-libfoo-0-1-2.dll.a
> > | +-foo.os
> > | +-foo.cpp
> > | +-/bin/g++
> > +-main.cpp
> > +-main.exe
> > | +-main.o
> > | | +-main.cpp
> > | | +-foo.hpp
> > | | +-/bin/g++
> > | +-/bin/g++
> > +-main.o
> > | +-main.cpp
> > | +-foo.hpp
> > | +-/bin/g++
> > +-SConstruct
> > scons: building terminated because of
> > errors.
> >
> > This is for SCons 2.3.6:
> >
> > ptomulik at mwnotebook:$ scons --tree=all
> > scons: Reading SConscript files ...
> > scons: done reading SConscript files.
> > scons: Building targets ...
> > g++ -o foo.os -c -I. foo.cpp
> > g++ -o cygfoo-0-1-2.dll
> > -Wl,-no-undefined -shared
> > -Wl,-Bsymbolic
> > -Wl,--out-implib,cygfoo-0-1-2.a
> > -Wl,--out-implib=libfoo-0-1-2.dll.a
> > -Wl,--export-all-symbols
> > -Wl,--enable-auto-import
> > -Wl,--whole-archive foo.os
> > -Wl,--no-whole-archive -L.
> > g++ -o main.o -c -I. main.cpp
> > g++ -o main.exe -Wl,-no-undefined main.o
> > -L. -lfoo
> > /bin/ld: cannot find -lfoo
> > collect2: error: ld returned 1 exit
> status
> > scons: *** [main.exe] Error 1
> > +-.
> > +-cygfoo-0-1-2.dll
> > | +-foo.os
> > | +-foo.cpp
> > | +-/bin/g++
> > +-cygfoo.dll
> > +-foo.cpp
> > +-foo.hpp
> > +-foo.os
> > | +-foo.cpp
> > | +-/bin/g++
> > +-libfoo-0-1-2.dll.a
> > | +-foo.os
> > | +-foo.cpp
> > | +-/bin/g++
> > +-main.cpp
> > +-main.exe
> > | +-main.o
> > | | +-main.cpp
> > | | +-foo.hpp
> > | | +-/bin/g++
> > | +-/bin/g++
> > +-main.o
> > | +-main.cpp
> > | +-foo.hpp
> > | +-/bin/g++
> > +-SConstruct
> > scons: building terminated because of
> > errors.
> >
> > Could someone help me pls? What is the
> > proper way to write a
> > portable SConstruct file, such that the
> > attached project
> > could build
> > on Most platforms? Do I need a versioned
> > shared libs at
> > all on
> > cygwin? It seems like the SONAME stuff
> > does not apply here?
> >
> > --
> > Paweł Tomulik
> >
> >
> > _______________________________________________
> > Scons-users mailing list
> > Scons-users at scons.org
> > <mailto:Scons-users at scons.org>
> > <mailto:Scons-users at scons.org
> > <mailto:Scons-users at scons.org>>
> >
> >
> https://pairlist4.pair.net/mailman/listinfo/scons-users
> > [1]
> >
> >
> >
> >
> > Links:
> > ------
> > [1]
> >
> https://pairlist4.pair.net/mailman/listinfo/scons-users
> >
> >
> _______________________________________________
> > Scons-users mailing list
> > Scons-users at scons.org
> > <mailto:Scons-users at scons.org>
> > <mailto:Scons-users at scons.org
> > <mailto:Scons-users at scons.org>>
> >
> >
> https://pairlist4.pair.net/mailman/listinfo/scons-users
> >
> >
> > _______________________________________________
> > Scons-users mailing list
> > Scons-users at scons.org
> > <mailto:Scons-users at scons.org>
> > <mailto:Scons-users at scons.org
> > <mailto:Scons-users at scons.org>>
> >
> >
> https://pairlist4.pair.net/mailman/listinfo/scons-users
> >
> >
> >
> >
> > _______________________________________________
> > Scons-users mailing list
> > Scons-users at scons.org <mailto:Scons-users at scons.org>
> >
> https://pairlist4.pair.net/mailman/listinfo/scons-users
> >
> >
> >
> >
> >
> > --
> > Paweł Tomulik
> > Instytut Techniki Lotniczej i Mechaniki Stosowanej
> > Politechnika Warszawska
> > _______________________________________________
> > Scons-users mailing list
> > Scons-users at scons.org <mailto:Scons-users at scons.org>
> > https://pairlist4.pair.net/mailman/listinfo/scons-users
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Scons-dev mailing list
> > Scons-dev at scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
>
>
> --
> Pawel Tomulik
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150830/2895d5d6/attachment-0001.html>
More information about the Scons-dev
mailing list