Re: [Scons-dev] Tutorial for Linux versioned libraries

[Alexandre Feblot]

Hi, Anatoly, I may not understand what you’re after (and especially your 5 questions), but I build and install versioned shared libraries successfully with SCons 2.3.4 on Linux (and since 2.3.2, I think). This PR (merged for 2.3.5 or 2.4) lets me use it properly too on Solaris: https://bitbucket.org/scons/scons/pull-request/186/attempt-to-fix-versionned-shared-library/diff There is a similar pending PR for AIX from Michael Haubenwallner : https://bitbucket.org/scons/scons/pull-request/144/emulate-svr4-linux-like-soname-on-aix/diff Maybe some other unix-like OS also need the same kind of fix, I don’t know. Installing a versioned shared lib works fine as well, but has a buggy side effect which I didn’t report when I discovered it because I had more important issues to fix: if you install a shared lib in <project_root>/a/b/c/d/dest/, that will also create the empty dir <sharedLib_src_dir>/a/b/c/d/dest/ I attach a small sample which builds such a versioned shared lib and also shows the install issue.

bugSconsInstallSharedLib.tgz
Description: Binary data

Le 18 mai 2015 à 13:49, anatoly techtonik <techto...@gmail.com> a écrit : On Fri, May 15, 2015 at 5:58 PM, Bill Deegan <b...@baddogconsulting.com> wrote: Anatoly, This message would have been better sent to the users mailing list. Not really. Here the recent thread in this list that says that mentions http://scons.tigris.org/issues/show_bug.cgi?id=2869 and says that it is nowhere near fixed. https://www.mail-archive.com/scons-dev@scons.org/msg02303.html So, the questions are: 1. What is the matter with shared libraries in layman terms? 2. What is the system logic to handle them? 3. What is the compiler toolchain logic to produce them? 4. What is the currently implemented SCons logic? 5. Why it is wrong? This is important to be able to fix this stuff. But also important for me to fix this RHVoice issue. I'm taking a look at it now. I'm fairly certain this issue is handled (at least in default branch and 2.3.4). If it is fixed in 2.3.4 then http://scons.tigris.org/issues/show_bug.cgi?id=2869 should mention what exactly was fixed and where it is documented, because the comment says that it was fixed in 2.2.0 and the was about recent version as I see it. The main SConstruct set's the soname and doesn't use the SCons logic to do the shared library versioning: Right. And I unable to understand what should be the idea behind. src/SConstruct  (line 165)   if sys.platform.startswith("linux"): env.Append(SHLINKFLAGS="-Wl,-soname,${TARGET.file}.${libversion.split('.')[0]}") If I comment out those lines (taking shared library versioning out of the picture) I get the following error: python src/nvda-synthDriver/RHVoice.py -o say.wav "say something" RHVoice 0.5.1 RHVoice_tts_engine_struct: No language resources are available Traceback (most recent call last):  File "src/nvda-synthDriver/RHVoice.py", line 285, in <module>    main()  File "src/nvda-synthDriver/RHVoice.py", line 235, in main    raise RuntimeError("RHVoice: engine initialization error") RuntimeError: RHVoice: engine initialization error "RHVoice 0.5.1" string means the .so is loaded ok. I've sent a pull request with the changes: https://github.com/techtonik/RHVoice/pull/1 Thanks. I need to understand the issue better before merging it. 1. If RHVoice needs those version numbers at all? 2. Why it tries to load so.0 when there is .0.0.0? _______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev

_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev