[Scons-dev] [Scons-users] SharedLibrary + SHLIBVERSION and cygwin
Paweł Tomulik
ptomulik at meil.pw.edu.pl
Sun Aug 30 10:04:54 EDT 2015
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shlib-test-1.tar.gz
Type: application/gzip
Size: 1935 bytes
Desc: not available
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150830/b341b6fc/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shlibversion-test.tar.gz
Type: application/gzip
Size: 3885 bytes
Desc: not available
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150830/b341b6fc/attachment-0003.bin>
More information about the Scons-dev
mailing list