Thanks Tor, this is all good to know! --- On Wed, 9/14/11, Tor Lillqvist <[email protected]> wrote: ... > > The question is why do we need > this? I would think > > all supported platforms have standard conformant > > C/C++ libs. > > Yeah, but the code uses non-standard library functions, > apparently.
Both of these appear to be standard (now?) > See external/glibc/makefile.mk. Apparently what's needed is > getopt() In FreeBSD we were using an independent library in some ports to support getopt_long but the regular library now supports the GNU extensions. If it's needed it can be taken from there. > and readdir_r(). > Quote from: http://womble.decadent.org.uk/readdir_r-advisory.html " OpenOffice.org (at least version 1.1.3) The code that enumerates fonts and plugins in the appropriate directories uses a stack buffer of type long[sizeof(struct dirent) + _PC_NAME_MAX + 1]. I can only assume this is the result of a programmer cutting his crack with aluminium filings. " I just don't like using extensions but the code has to be reviewed. > > In the same line of questioning, but not a license > > issue, why do we need STLport? > > (In LibreOffice we don't use STLport any more on any > platform.) Your code presumably still relies on some > STLport stuff on Windows. Anyway, even if AOOo itself > wouldn't use STLport itself, if you want to be binary > compatible with binary extensions, those might rely > on the OOo installation containing a STLport shared > library so you need to build and ship it. > I think we should just follow LO on this one. The STLport OOo carries is outdated and the latest versions in sourceforge (2008) are not very well maintained (broken on MacOS X and BSD, AFAICT). Pedro.
