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 <[email protected] > <mailto:[email protected]>> 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@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 > <[email protected] <mailto:[email protected]>> 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@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@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 > <[email protected] <mailto:[email protected]>> wrote: > > Hi, any ideas here? > > W dniu 2015-08-18 23:11, Paweł Tomulik pisze: > > No, it doesn't seem to help: > > > ptomulik@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@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 > <[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> 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 > <[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> 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@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@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@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 > [email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > > https://pairlist4.pair.net/mailman/listinfo/scons-users > [1] > > > > > Links: > ------ > [1] > https://pairlist4.pair.net/mailman/listinfo/scons-users > > _______________________________________________ > Scons-users mailing list > [email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > > https://pairlist4.pair.net/mailman/listinfo/scons-users > > > _______________________________________________ > Scons-users mailing list > [email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > > https://pairlist4.pair.net/mailman/listinfo/scons-users > > > > > _______________________________________________ > Scons-users mailing list > [email protected] <mailto:[email protected]> > https://pairlist4.pair.net/mailman/listinfo/scons-users > > > > > > -- > Paweł Tomulik > Instytut Techniki Lotniczej i Mechaniki Stosowanej > Politechnika Warszawska > _______________________________________________ > Scons-users mailing list > [email protected] <mailto:[email protected]> > https://pairlist4.pair.net/mailman/listinfo/scons-users > > > > > > > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > -- Pawel Tomulik
shlib-test-1.tar.gz
Description: application/gzip
shlibversion-test.tar.gz
Description: application/gzip
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
