Did you try the patch as a short term solution? On Aug 30, 2015 10:15 AM, "Paweł Tomulik" <[email protected]> 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 <[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 > > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
