Hey Stanislav, 2008/5/2 Stanislav Brabec <[EMAIL PROTECTED]>: > Arnaud Quette wrote: > > > I've seen another mail from a SuSE guy, and fwded by Arjen, about > > libtool and possibly dependencies. I gotta check it. > > Probably Andreas Schwab. His patch (see the attachment) applies on > 2.2.2, but breaks the build. Without his patch, it fails on IA64 and > S390. I will look deeper into it:
any news on that side? I've not yet taken time to investigate deeper this point. > gcc -DHAVE_CONFIG_H -I. -I../include -I../include -O2 -fmessage-length=0 > -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -Wall -Wsign-compare -MT > parseconf.lo -MD -MP -MF .deps/parseconf.Tpo -c parseconf.c -fPIC -DPIC -o > .libs/parseconf.o > mv -f .deps/state.Tpo .deps/state.Po > mv -f .deps/parseconf.Tpo .deps/parseconf.Po > mv -f .deps/common.Tpo .deps/common.Po > rm -f libcommon.a > /usr/bin/ar cru libcommon.a common.o > ranlib libcommon.a > mv -f .deps/parseconf.Tpo .deps/parseconf.Plo > mv: cannot stat `.deps/parseconf.Tpo': No such file or directory > make[1]: *** [parseconf.lo] Error 1 > make[1]: Leaving directory `/usr/src/packages/BUILD/nut-2.2.2-pre3/common' > > make: *** [all-recursive] Error 1 > > I am attaching one another cosmetic patch. It prevents warning mentioned > in the patch preamble, which is considered as error by SuSE QA tools. > Adding an explicit cast lets to know to the compiler, that cast from > integer for void * is really intended here. I've fixed these calls to conform to the function's prototype (commit underway). btw, is there a central point for accessing NUT related stuffs in opensuse (source packages with patchs, QA reports, ...) > Arnaud Quette wrote: > > > I've tested it with "make -j2", and 2 config set (--disable-shared for > > full static, and --enable-static for linking clients on the shared lib > > while still shipping the static lib) and everything seems fine. > > Can you confirm on your side? > > Yes, it seems to fix parallel build. Tried ~10 times, no failure. perfect > Regarding my hald-addon path patch - it is an intermediate solution, > which will probably break in SuSE: > > https://bugzilla.novell.com/show_bug.cgi?id=304316 > > But I guess that upstream will take care of correct setting of > hald-addon directory (see bugs in my previous mail). well, I've asked Dave and Danny to complete hal.pc and provide these dirs for long. I hope it will succeed since their solution (the current method in NUT) is suboptimal! What is missing (if you can add this comment to https://bugs.freedesktop.org/show_bug.cgi?id=15768) is the .fdi path (something like hal_fdidir) to be able to install our .fdi file, since we won't be able to guess the right path otherwise. Note that this is less mandatory since we're not on a binary dependent path here. however, I'm preparing an early fix in m4/nut_check_libhal.m4, so that when the HAL fix is released, we're already ready. or at least, the needed change would be limited to the final variable name... cheers, Arnaud -- Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://people.debian.org/~aquette/ Free Software Developer - http://arnaud.quette.free.fr/ _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
