On Aug 29, 2011, at 2:50 PM, Matúš Kukan wrote: > On 29 August 2011 09:48, Stephan Bergmann > <stephan.bergmann.second...@googlemail.com> wrote: >> On Aug 28, 2011, at 11:57 PM, Matúš Kukan wrote: >>> I was working on gbuildizing sal and few problems showed up: >>> >>> 1, in sal/osl/unx/system.h:75 there is #if GLIBC >= 2 >>> but I could not find how is GLIBC defined. In Env.Host.sh I have >>> GLIBC="2REDHAT60" but that is something else probably. >>> (wrong branch in #if .. #else .. is executed for me) >> >> solenv/inc/unxlng.mk: CDEFS+=-DGLIBC=2 >> > So it is 2 for linux and macosx and else undefined and we are > comparing it to 2 ? > Could the else branch be removed and first executed unconditionally > because we are in #ifdef LINUX part ? > Probably in the past was possible to have GLIBC < 2.
Yes, more than likely something that can be cleaned up (as already suggested by Rene) by removing GLIBC from sal/osl/unx/system.c, sal/osl/unx/system.h, solenv/inc/unxlng.mk, solenv/inc/unxmacx.mk, and probably also solenv/inc/doxygen.cfg. >>> 2. Then also somewhere has to be defined architecture for >>> rtl/source/macro.hxx, but I could not find where it is for build >>> and may be we need add this to gbuild/platform/* >> >> solenv/inc/settings.mk: CDEFS=-D$(OS) >> > OS is the first part, it's defined also in gbuild but the second part > with processor caused trouble. > I found -D$(CPUNAME) in settings.mk. > That's INTEL for me but there is chaos about this cpu thing. > There is also X86 defined in unxlngi.mk. > In gbuild/platform/*.mk, somewhere is -D$(CPUNAME) but for > linux-INTEL.mk there is -DX86. > So my architecture is unsupported in gbuild because macro.hxx is > checking for INTEL. > Is it possible we need X86 to be defined somewhere. I'd just use > -D$(CPUNAME) and no manually added constants. > Do we need also CPUNAME and also these constants in platform specific > makefiles ? Interesting. ;-) So, its definitely worth cleaning this mess up, consolidating on a single define, either INTEL or X86. However, probably a lot of work, and you maybe also need to take care of URE/SDK compatibility. In any event, I would do that cleanup *before* working on gbuildizing sal. >>> 3. There were functions which are visible in library but are not in >>> exported headers and not used in LibreOffice outside sal >>> and are listed in qa/helper/gcov/deprecated.txt (there are also >>> other functions listed) >> >> Do you have an example of such a function? >> > rtl_hashfunc, rtl_hashentry_destroy and 5 more rtl_hashtable_* from > rtl/source/locale.c Ah, I see. Yes, indeed, appears they have erroneously been added to sal.map once, and should not be removed for interface stability. > and I forgot to ask what n means in build.lst, w=windows, u=unx.. but n= ? > It's for win32 directories. Are we building it on windows or is it > something old, unused ? IIRC, n (not w) is used for Windows (i.e., Windows NT, rather than 16-bit Windows). -Stephan _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
