On 12/7/11 12:06 AM, Mathias Bauer wrote:
Am 06.12.2011 21:35, schrieb Ariel Constenla-Haile:
yes, this looked quit strange, and I didn't notice it was trying to link
against salcpprt until I tested a clean build with only one process. It
seems building with multi-processes is a bit tricky, because the build
tries to go on as far as it can. So you may try to rebuild the broken
module after build.pl stops, and it may seem to build find; in this
case, sal seems to be build in parallel with that broken module, so you
don't notice the dependency.
You perfectly described why we started to work on the new build system
based on a single process make in the first place. :-)
So, it does try to link against ucpp.
The switch seems to come from solenv/inc/unxlng.mk#226
LIBSALCPPRT*=-Wl,--whole-archive -lsalcpprt -Wl,--no-whole-archive
That alone isn't wrong - the question is why is LIBSALCPPRT used as a
linker input? I can't find that anywhere in the makefile. Perhaps it's
one of the "clever" automatic dependencies that the old build system
added at its own will, e.g. the automatic dependency on uwinapi.dll in
every Windows library that I once removed in a painful procedure.
Instead of adding a dependency on sal I would rather recommend to look
for the place where this obviously wrong dependency is added. Maybe I
can find some time in the next days.
i will have a look in it as well when i find the time. I haven't noticed
this problem when i had build and tested it on several platforms
(including Ubuntu). I will try Fedora as well, i am not sure if i had
test it there...
I had first a gnu make file but then i noticed that the patch mimic
isn't ready to use in a gnu make file. Maybe i should have checked in
the source directly because they are license compatible ;-)
Juergen
