[NTLK] Followup: Need help with compiling and running WatsonEnabler

[David Arnold]

> On 22 Feb 2022, at 10:49, NewtonTalk <newtontalk at pda-soft.de> wrote:
> 
> David, Silvain, first of all, thanks a lot for your help.
> 
>> Perhaps the details might be better off list, but ?
> 
> I'd rather we kept them on-list. Had I been able to find this information in
> the NewtonTalk archives yesterday, I might have been able to solve this
> problem on my own. Keeping this information on the list might make the life
> of the next person willing to go on this crusade a little easier.

Fine with me.  NTLKers, if this gets overwhelming, please speak up.


>> With g++ installed, Paul?s instructions above appeared to work fine for me.
> 
> After installing g++, they worked fine for me, too.

Great!

<...>

> Since I remembered Silvain telling me that some library must be copied to
> /usr/local/lib, I took the liberty to assume that libDCL.so is in fact this
> library. So I copied it to /usr/local/lib. Since I just succeeded in
> creating a Watson-compatible NewtTest package by 
> 
>   a) navigating to the folder "build/Sample_Code/PackageUtils" and 
> 
>   b) calling "WatsonEnabler NewtTestOriginal.pkg NewtTestWatson.pkg"
> 
> I'm assuming my assumption must have been correct.

The .so file is a “shared object”, the Linux equivalent of a Windows DLL.  macOS calls theirs a .dylib, fwiw.

There are three (main) ways that a Linux executable can find its shared objects:
- the system path,
- the LD_LIBRARY_PATH environment variable, or
- the “rpath” built into the executable.

The system path is controlled by the /etc/ld.so.conf file.  On my Ubuntu box, this includes all the files in /etc/ld.so.conf.d/*.conf.  That in turn has libc.conf, and in it you’ll find: /usr/local/lib.   So that’s why copying the file there works.

The environment variable approach is useful mostly for testing or augmenting the system configuration to include your own personal collection of libraries.  It can sometimes be useful during development, especially if you’re working on a new version of a system library, and you want to be sure that your copy is used instead of the standard one.

The “rpath” approach is useful when you’re building something for distribution, but don’t want to install your .so files into a system directory.  You can supply the -rpath option to the linker when building the executable, and it will embed the supplied path into the executable binary (using the DT_RUNPATH attribute).  Your installer can then place the files in that location, and the executable will find them.

The ld.so man page will have lots of details here: try ‘man ld.so’ if you want to delve further.

Perhaps also worth mentioning: a static library (a .lib file) has its embedded objects copied into the executable file during linking, which avoids all these issues.  If you ever need to distribute a Linux executable it’s probably worth figuring out how to get the DCL code in static library form so you can avoid all this messing about with shared objects.




d