Nick Leverton wrote:

> In article <nfi6e4$c7s$1@...>,
> deloptes 
>
<trinity-devel@...>
> wrote:
>>Fat-Zer wrote:
>>
>>> The testing framework wasn't introduced with migration to cmake. I
>>> believe that autotools unittests are broken as well now...
>>> IMHO it would be great to bring unittesting back, but this is a bit
>>> tough tasks which will be likely postponed forever... I personally not
>>> familiar with cmake testing in general...
>>
>>Thanks for looking into my issues
>>Is there a way in your opinion how we can test the vcardparser?
>>I was thinking overwriting the library files, but I'm not sure if the
>>libtdeabc.so.1.2.0 is the only one I should overwrite and if I have to
>>restart or reboot or whatever
> 
> You could perhaps set the LD_LIBRARY_PATH environment variable to point
> to your test libraries and run an existing program against them.
> The Linux loader ld.so searches directories named in LD_LIBRARY_PATH
> before falling back to the system library directories.  For instance
> 
> LD_LIBRARY_PATH=/path/to/libs/ kaddressbook
> 
> See "man ld.so" for full details.
> 
> Nick

Thank you for the advise. I was also thinking of doing something like this.
I know ld pretty well BTW, but in the case of the tdelibs I am not sure,
because there are many libs besides the libtdeabc.so. I'm not sure how it
will behave and don't want to experiment that much. Not that I do not like
it, but because recently the available time is short and I try to focus on
one problem. It happens as usual: you dig a bit in the hope you'll fix
something and than you hit another issue - dig a bit and s.o.

I'll give it a try. I suppose ldd will tell me if the app is getting the lib
of interest loaded.

regards