25 Apr
2016
25 Apr
'16
10:39 p.m.
Nick Leverton wrote:
In article <nfi6e4$c7s$1(a)ger.gmane.org>rg>,
deloptes
<trinity-devel(a)lists.pearsoncomputing.net>
wrote:
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
Fat-Zer wrote:
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 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