Re: [Libreoffice] Problem with sal/cppunittester

On 05/11/10 21:36, Caolán McNamara wrote:
> On Fri, 2010-11-05 at 21:10 +0000, Wols Lists wrote:
> > Just doing an emerge cppunit.
> It shouldn't be necessary to use system cppunit, cppunit should be built
> as part of the build.

And now I've played, if you ask for system cppunit and it's not there,
it bombs with an error message just fine, so that's okay.

So the only problem is this where it defaults to "build your own" and
then fails to do so ...

> So, lets just document debugging this...
>
> sal/cppunittester/makefile.mk has 
>
> APP1STDLIBS = $(CPPUNITLIB) $(SALLIB)
>
> in it, 
>
> solenv/inc/libs.mk 
> has 
>
> CPPUNITLIB = -lcppunit
>
> for the case where we build our own cppunit
>
> check your solver/330/unxlng*.pro/lib/ and see is there a libcppunit.so
> in there. You'll probably find that there isn't, but that there is a
> libcppunit-1.12.so.1 but no libcppunit.so.

Spot on.

>  Missing link maybe. Because
> I'm not building from scratch everytime I happen to have the link from
> earlier, which is probably also why a lot of other people don't see this
> yet.
>
> hmm, so cd cppunit and see what changed recently, 
>
> git log -n 10
>
> one of them (11c3398a91d7f65a45e08ad4ee33bdb5a7355111) says something a
> modifications to "cppunit library name", hum ho, that sounds likely
>
> git show 11c3398a91d7f65a45e08ad4ee33bdb5a7355111
>
> shows a change to the prj/d.lst i.e.
>
> +..\%__SRC%\lib\libcppunit-1.12.so.1.0 %_DEST%\lib%_EXT%
> \libcppunit-1.12.so.1.0
> +symlink: %_DEST%\lib%_EXT%\libcppunit-1.12.so.1.0 %_DEST%\lib%_EXT%
> \libcppunit.so
>
> revert that chunk, i.e. remove the symlink: line which mentions
> libcppunit-1.12.so.1.0 (not the one that says libcppunit-1.12.so.1) and
> it should work.
Done that, and it does work. Unfortunately, I don't seem to be able to
create a patch. I'm in libreoffice.../cppunit where my changes are, and
it claims "master is clean". Odd...

> so apparently for some reason having *two* lines with symlink: in it
> with the same target breaks (which is news to me). Someone should have a
> look at deliver in the solenv to find what it does on seeing a
> "symlink:" line and try and fix it to do the right thing.
I'm wondering if the second source doesn't exist, so it's deleting the
target and then, with no source, it's unable to create the .so the
second time around ... (but that's just y speculation)

> C.
Cheers,
Wol