On Wed, 2011-02-09 at 10:16 +0100, Francois Tigeot wrote: > On Wed, Feb 09, 2011 at 08:47:46AM +0100, Francois Tigeot wrote: > > > > I don't think --enable-new-dtags was the culprit. I have updated the sources > > with g pull since my last mail and I only get these errors now: > > > > /usr/libexec/binutils217/elf/ld: cannot find -luno_sal > > /usr/libexec/binutils217/elf/ld: cannot find -lcosv > > > > Seems like the same sort of trouble I had, only directly with ld instead > > of g++ > > Correction: it is not the same issue. This time, the files are not where > dmake think they are. > > I have libuno_sal.so files in: > solver/330/unxdflyx3.pro/lib/libuno_sal.so > clone/ure/sal/unxdflyx3.pro/lib/libuno_sal.so > > The failing command runs from: > salhelper/source > > with -L../unxdflyx3.pro/lib > > The problem is salhelper/source/../unxdflyx3.pro/lib is empty and > libuno_sal.so is in salhelper/source/../../sal/unxdflyx3.pro/lib > > I'm not sure what file should be where; the amount of symbolic links is a > bit confusing...
So libuno_sal.so should indeed be built into sal/unxdflyx3.pro/lib/libuno_sal.so so that looks fine, "deliver" should automatically link/copy it to solver/330/unxdflyx3.pro/lib/libuno_sal.so so that looks fine. so if you do a export VERBOSE=true and run dmake as per the build failed message shown you should have a g++ line like... g++ ... -L../unxdflyx3.pro/lib ... -L/path/to/solver/330/unxdflyx3.pro/lib so check if /path/to/solver is correct, perhaps the source/buildtree got moved or moved around. Is this head or 3.3.X branch ? C. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
