[Scons-users] [Scons-dev] Tutorial for Linux versioned libraries

[Bill Deegan]

Anatoly,

This message would have been better sent to the users mailing list.

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).

The main SConstruct set's the soname and doesn't use the SCons logic to do
the shared library versioning:
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


I've sent a pull request with the changes:
https://github.com/techtonik/RHVoice/pull/1

-Bill


-Bill

On Fri, May 15, 2015 at 2:25 AM, anatoly techtonik <techtonik at gmail.com>
wrote:

> Hi,
>
> If I understand the problem correctly, the issue with
> versioned libraries is not fixed yet:
> http://scons.tigris.org/issues/show_bug.cgi?id=2869
>
>
> From times I used to code on low C level my primary
> system was Windows, so I miss all the background
> about about versioned libraries domain, but I am
> interested to resolve this issue in SCons.
>
> I have a good use case for that. I am enhancing a
> voice synthesizer for blind computer users. It was
> created by a blind girl and she used SCons as a build
> system (which says something about it).
>
> First, I am trying to provide a Python interface for it
> using ctypes. The windows part works fine - I place
> RHVoice.dll near RHVoice.py and then execute
>
> > RHVoice.py -o say.wav "say something beautifully"
>
> You can try it yourself (wine?):
> https://ci.appveyor.com/project/techtonik/rhvoice/build/1.0.13/artifacts
>
>
> But on Linux it is complicated.
>
> $ git clone https://github.com/techtonik/RHVoice.git
> $ cd RHVoice
> $ git checkout d526ba60
> $ scons
> $ python src/nvda-synthDriver/RHVoice.py -o say.wav "say something"
> detected dll/so path: /home/user/RHVoice/build/linux/lib/libRHVoice.so
> ...
> OSError: libRHVoice_core.so.0: cannot open shared object file: No such
> file or directory
>
> The .so file loaded with ctypes is libRHVoice.so, the
> other .so file - libRHVoice_core.so - is a dependency
> and it was built in sibling core/ directory.
>
> $ ls build/linux/core/libRHVoice_core.so
> build/linux/core/libRHVoice_core.so
>
> However, even if I add this dir to LD_LIBRARY_PATH,
> the .so still can not be found, because generated file
> doesn't have .0 extension
>
> $ LD_LIBRARY_PATH=/home/user/RHVoice/build/linux/core python
> src/nvda-synthDriver/RHVoice.py -o say.wav "say something again"
>
>
> I can rename file to have .0 extension (or load core .so
> with ctypes explicitly), but this is a workaround, and
> not a solution, so while I am not cursed with knowledge,
> and interested to solve it, the questions are:
>
> 1. Extension is an ABI version, who should set it?
> a. gcc
> b. scons
> c. ?
>
> 2. The SConstruct files have some Install targets, that
> produce both .so files in the same directory:
>
> $ scons install prefix=$PWD/outdir
> ...
> $ ls outdir/lib
> libRHVoice_core.so.0.0.0  libRHVoice.so.2.0.0
>
> As you may see, the libs produced by install have
> those prefixes. I thought that these should be added by
> compiler automatically, but it appears that at least 0.0.0
> is in SConscripts file.
>
> Now the problem with those is that even if I load
> versioned libRHVoice.so.2.0.0 with ctypes, it still tries to
> load dependency libRHVoice_core.so.0 which is again
> absent.
>
>
> So, who should add those suffixes (gcc or scons)?
> Why main lib insists that it should load core with
> so.0?
> Are these versions should be specified in SConstruct
> or gcc should figure them out from the sources?
>
>
> What are the best practices in C on Linux to use
> versioned libraries?
> What is the current SCons strategy to deal with them?
> What is the strategy that should be implemented to
> solve the
> http://scons.tigris.org/issues/show_bug.cgi?id=2869 ?
>
> --
> anatoly t.
> _______________________________________________
> 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://pairlist4.pair.net/pipermail/scons-users/attachments/20150515/37b9c97b/attachment.html>