[Libreoffice] few queastions about building sal

[Stephan Bergmann]

On Aug 29, 2011, at 2:50 PM, Matúš Kukan wrote:
> On 29 August 2011 09:48, Stephan Bergmann
> <stephan.bergmann.secondary at 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