Re: How to do with glibc-2.1.3 in AOOo?
On Wed, Sep 14, 2011 at 3:42 PM, Tor Lillqvist t...@iki.fi 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. See external/glibc/makefile.mk. Apparently what's needed is getopt() and readdir_r(). 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. that is correct but i would say it's a minor issue. Extensions where the source is available can be easy recompiled and others have to be recompiled by the vendor if they are still supported. I don't expect too many C++ extensions because of well known reasons. If we detect critical C++ extensions that are not longer supported we can handle them special. Especially for C++ extensions i would always recommend to use a max version dependency. In the long term i would suggest that we remove STL_port as well and use the compiler version. side step - better addressed in a new thread, excuse me By the way it would be very nice if such work on the code could be shared between the projects that rely more or less on the same base ;-) Independent on the promotion, supporting, etc. on a specific brand we should really think how we can come back to one common source to bundle the developer resources. In the long term we have only success if we work together because our goal is the same. The best free available and stable office productivity suite. Juergen --tml
RE: How to do with glibc-2.1.3 in AOOo?
Support for w_char matters to me, but that is unrelated to work here. However, there's another place to look. I know there are command-line utilities in Subversion releases, so I went nosing around. There is an apr_lib.h reference and apr_getopt... calls. I haven't found the library and its source yet, but I bet it might have what is needed for Apache OOo. It might take some preprocessor magic to rename back in a custom getopt.h file. I did trace back enough to know that here are some interesting places to look further: http://archive.apache.org/dist/apr/apr-1.4.5.tar.bz2 http://archive.apache.org/dist/apr/apr-util-1.3.12.tar.bz2 - Dennis -Original Message- From: Pedro Giffuni [mailto:giffu...@tutopia.com] Sent: Wednesday, September 14, 2011 22:39 To: ooo-dev@incubator.apache.org Subject: Re: How to do with glibc-2.1.3 in AOOo? On Thu, 15 Sep 2011 08:06:40 +0300, Tor Lillqvist t...@iki.fi wrote: For command line options I think the normal char is enough I don't know what the OOo code actually uses getopt() for (I am pretty sure it is just some build-time tools that actually use it...), but you can be assured that the actual OOo executable(s), for Windows (which presumably *is* the OS you expect most of your users to have?), definitely do need the full original Unicode command line. (Remember that Windows is Unicode-based, all file names and other system interfaces are in UTF-16.) And of course the OOo code itself uses UTF-16 strings almost exclusively. Indeed, I had forgotten: http://dvice.com/archives/2009/01/klingon_keyboar.php :) Cheers, Pedro.
Re: How to do with glibc-2.1.3 in AOOo?
http://apr.apache.org/docs/apr/1.4/apr__getopt_8h-source.html http://svnbook.red-bean.com/en/1.5/svn.developer.usingapi.html On Sep 15, 2011, at 1:41 PM, Dennis E. Hamilton wrote: Support for w_char matters to me, but that is unrelated to work here. However, there's another place to look. I know there are command-line utilities in Subversion releases, so I went nosing around. There is an apr_lib.h reference and apr_getopt... calls. I haven't found the library and its source yet, but I bet it might have what is needed for Apache OOo. It might take some preprocessor magic to rename back in a custom getopt.h file. I did trace back enough to know that here are some interesting places to look further: http://archive.apache.org/dist/apr/apr-1.4.5.tar.bz2 http://archive.apache.org/dist/apr/apr-util-1.3.12.tar.bz2 - Dennis -Original Message- From: Pedro Giffuni [mailto:giffu...@tutopia.com] Sent: Wednesday, September 14, 2011 22:39 To: ooo-dev@incubator.apache.org Subject: Re: How to do with glibc-2.1.3 in AOOo? On Thu, 15 Sep 2011 08:06:40 +0300, Tor Lillqvist t...@iki.fi wrote: For command line options I think the normal char is enough I don't know what the OOo code actually uses getopt() for (I am pretty sure it is just some build-time tools that actually use it...), but you can be assured that the actual OOo executable(s), for Windows (which presumably *is* the OS you expect most of your users to have?), definitely do need the full original Unicode command line. (Remember that Windows is Unicode-based, all file names and other system interfaces are in UTF-16.) And of course the OOo code itself uses UTF-16 strings almost exclusively. Indeed, I had forgotten: http://dvice.com/archives/2009/01/klingon_keyboar.php :) Cheers, Pedro.
RE: How to do with glibc-2.1.3 in AOOo?
On Thu, 15 Sep 2011 13:41:39 -0700, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Support for w_char matters to me, but that is unrelated to work here. The idea is simply to replace some glibc routines in the stubs package. If the gnu version supports w_char, then it matters, otherwise using the BSD/OpenGroup version is just fine. However, there's another place to look. I know there are command-line utilities in Subversion releases, so I went nosing around. There is an apr_lib.h reference and apr_getopt... calls. I haven't found the library and its source yet, but I bet it might have what is needed for Apache OOo. It might take some preprocessor magic to rename back in a custom getopt.h file. Nice find! http://apr.apache.org/ I don't see why we should do such preprocessing, we may need to replace more stuff than just readdir_r and getopt. If that's the case, Then we could just bring in all the Apache Portable Runtime. We would be replacing glic with APR, looks good to me but it ultimately depends on who will do it. Pedro. I did trace back enough to know that here are some interesting places to look further: http://archive.apache.org/dist/apr/apr-1.4.5.tar.bz2 http://archive.apache.org/dist/apr/apr-util-1.3.12.tar.bz2 - Dennis -Original Message- From: Pedro Giffuni [mailto:giffu...@tutopia.com] Sent: Wednesday, September 14, 2011 22:39 To: ooo-dev@incubator.apache.org Subject: Re: How to do with glibc-2.1.3 in AOOo? On Thu, 15 Sep 2011 08:06:40 +0300, Tor Lillqvist t...@iki.fi wrote: For command line options I think the normal char is enough I don't know what the OOo code actually uses getopt() for (I am pretty sure it is just some build-time tools that actually use it...), but you can be assured that the actual OOo executable(s), for Windows (which presumably *is* the OS you expect most of your users to have?), definitely do need the full original Unicode command line. (Remember that Windows is Unicode-based, all file names and other system interfaces are in UTF-16.) And of course the OOo code itself uses UTF-16 strings almost exclusively. Indeed, I had forgotten: http://dvice.com/archives/2009/01/klingon_keyboar.php :) Cheers, Pedro.
Re: How to do with glibc-2.1.3 in AOOo?
Yes, apr_getopt calls in Subversion would come from one of those two libraries. If you need a minimal example I suggest subversion/svnversion/main.c and subversion/tests/cmdline/atomic-ra-revprop-change.c. Dennis E. Hamilton wrote on Thu, Sep 15, 2011 at 13:41:39 -0700: Support for w_char matters to me, but that is unrelated to work here. However, there's another place to look. I know there are command-line utilities in Subversion releases, so I went nosing around. There is an apr_lib.h reference and apr_getopt... calls. I haven't found the library and its source yet, but I bet it might have what is needed for Apache OOo. It might take some preprocessor magic to rename back in a custom getopt.h file. I did trace back enough to know that here are some interesting places to look further: http://archive.apache.org/dist/apr/apr-1.4.5.tar.bz2 http://archive.apache.org/dist/apr/apr-util-1.3.12.tar.bz2 - Dennis -Original Message- From: Pedro Giffuni [mailto:giffu...@tutopia.com] Sent: Wednesday, September 14, 2011 22:39 To: ooo-dev@incubator.apache.org Subject: Re: How to do with glibc-2.1.3 in AOOo? On Thu, 15 Sep 2011 08:06:40 +0300, Tor Lillqvist t...@iki.fi wrote: For command line options I think the normal char is enough I don't know what the OOo code actually uses getopt() for (I am pretty sure it is just some build-time tools that actually use it...), but you can be assured that the actual OOo executable(s), for Windows (which presumably *is* the OS you expect most of your users to have?), definitely do need the full original Unicode command line. (Remember that Windows is Unicode-based, all file names and other system interfaces are in UTF-16.) And of course the OOo code itself uses UTF-16 strings almost exclusively. Indeed, I had forgotten: http://dvice.com/archives/2009/01/klingon_keyboar.php :) Cheers, Pedro.
Re: How to do with glibc-2.1.3 in AOOo?
Dave Fisher wrote on Thu, Sep 15, 2011 at 14:17:43 -0700: http://apr.apache.org/docs/apr/1.4/apr__getopt_8h-source.html http://svnbook.red-bean.com/en/1.5/svn.developer.usingapi.html That's an old/previous release of the book. Also: http://subversion.apache.org/HACKING On Sep 15, 2011, at 1:41 PM, Dennis E. Hamilton wrote: Support for w_char matters to me, but that is unrelated to work here. However, there's another place to look. I know there are command-line utilities in Subversion releases, so I went nosing around. There is an apr_lib.h reference and apr_getopt... calls. I haven't found the library and its source yet, but I bet it might have what is needed for Apache OOo. It might take some preprocessor magic to rename back in a custom getopt.h file. I did trace back enough to know that here are some interesting places to look further: http://archive.apache.org/dist/apr/apr-1.4.5.tar.bz2 http://archive.apache.org/dist/apr/apr-util-1.3.12.tar.bz2 - Dennis -Original Message- From: Pedro Giffuni [mailto:giffu...@tutopia.com] Sent: Wednesday, September 14, 2011 22:39 To: ooo-dev@incubator.apache.org Subject: Re: How to do with glibc-2.1.3 in AOOo? On Thu, 15 Sep 2011 08:06:40 +0300, Tor Lillqvist t...@iki.fi wrote: For command line options I think the normal char is enough I don't know what the OOo code actually uses getopt() for (I am pretty sure it is just some build-time tools that actually use it...), but you can be assured that the actual OOo executable(s), for Windows (which presumably *is* the OS you expect most of your users to have?), definitely do need the full original Unicode command line. (Remember that Windows is Unicode-based, all file names and other system interfaces are in UTF-16.) And of course the OOo code itself uses UTF-16 strings almost exclusively. Indeed, I had forgotten: http://dvice.com/archives/2009/01/klingon_keyboar.php :) Cheers, Pedro.
Re: How to do with glibc-2.1.3 in AOOo?
On Sep 14, 2011, at 10:56 AM, Shao Zhi Zhao wrote: glibc-2.1.3 is under GNU GPL 2 Really? I think it is http://www.gnu.org/software/libc/manual/html_node/Copying.html#Copying GNU LGPL 2.1. -- Pavel Janík
Re: How to do with glibc-2.1.3 in AOOo?
On Sep 14, 2011, at 11:17 AM, Shao Zhi Zhao wrote: unzip glibc-2.1.3-stub,open the file of COPYING, Where you have got this file? -- Pavel Janík
Re: How to do with glibc-2.1.3 in AOOo?
On Wed, 14 Sep 2011 12:26:53 +0200, Pavel Janík pa...@janik.cz wrote: On Sep 14, 2011, at 11:17 AM, Shao Zhi Zhao wrote: unzip glibc-2.1.3-stub,open the file of COPYING, Where you have got this file? It appears listed as external source tarball in the ApacheMigration wiki. The question is why do we need this? I would think all supported platforms have standard conformant C/C++ libs. In the same line of questioning, but not a license issue, why do we need STLport? cheers, Pedro.
Re: How to do with glibc-2.1.3 in AOOo?
From: Pavel Janík pa...@janik.cz Subject: Re: How to do with glibc-2.1.3 in AOOo? Date: Wed, 14 Sep 2011 12:26:53 +0200 On Sep 14, 2011, at 11:17 AM, Shao Zhi Zhao wrote: unzip glibc-2.1.3-stub,open the file of COPYING, Where you have got this file? http://ftp.gnu.org/gnu/libc/glibc-2.1.3.tar.gz GPL, not LGPL. -- Nakata Maho http://accc.riken.jp/maho/ , JA OOO http://ja.openoffice.org/ http://blog.goo.ne.jp/nakatamaho/ ,GPG: http://accc.riken.jp/maho/maho.pgp.txt
Re: How to do with glibc-2.1.3 in AOOo?
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. See external/glibc/makefile.mk. Apparently what's needed is getopt() and readdir_r(). 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. --tml
Re: How to do with glibc-2.1.3 in AOOo?
Thanks Tor, this is all good to know! --- On Wed, 9/14/11, Tor Lillqvist t...@iki.fi 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.
Re: How to do with glibc-2.1.3 in AOOo?
On 14.09.2011 17:23, Pedro F. Giffuni wrote: Thanks Tor, this is all good to know! --- On Wed, 9/14/11, Tor Lillqvist t...@iki.fi 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?) perhaps. but see below :) 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. if it's not in a C standard at least 20 years old then usually MSVC doesn't have it. 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). only reason why OOo ships STLport is ABI compatibility of the URE and for C++ UNO extensions. we wanted to get rid of it for OOo 4.0 anyway.
Re: How to do with glibc-2.1.3 in AOOo?
--- On Wed, 9/14/11, Michael Stahl wrote: ... 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. if it's not in a C standard at least 20 years old then usually MSVC doesn't have it. Yes :(. At least configure/autoconf could learn to avoid building the extra stuff on linux/BSD. ... only reason why OOo ships STLport is ABI compatibility of the URE and for C++ UNO extensions. we wanted to get rid of it for OOo 4.0 anyway. Sounds like something we could anticipate for AOOo too. The specific extension that requires it should provide it. Pedro.
RE: How to do with glibc-2.1.3 in AOOo?
If you list the functions you have in mind, and the names of the headers normally used to introduce their signatures, I will double-check the VC++ 2008 and VC++ 2010 libraries to see what the status is. - Dennis -Original Message- From: Michael Stahl [mailto:m...@openoffice.org] Sent: Wednesday, September 14, 2011 08:43 To: ooo-dev@incubator.apache.org Subject: Re: How to do with glibc-2.1.3 in AOOo? On 14.09.2011 17:23, Pedro F. Giffuni wrote: Thanks Tor, this is all good to know! --- On Wed, 9/14/11, Tor Lillqvist t...@iki.fi 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?) perhaps. but see below :) 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. if it's not in a C standard at least 20 years old then usually MSVC doesn't have it. 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). only reason why OOo ships STLport is ABI compatibility of the URE and for C++ UNO extensions. we wanted to get rid of it for OOo 4.0 anyway.
RE: How to do with glibc-2.1.3 in AOOo?
Ahem ... Guys; --- On Wed, 9/14/11, Dennis E. Hamilton dennis.hamil...@acm.org wrote: ... If you list the functions you have in mind, and the names of the headers normally used to introduce their signatures, I will double-check the VC++ 2008 and VC++ 2010 libraries to see what the status is. We are far from being the only unixy port to Windows: A quick google for getopt_long Windows returns: http://opensource.apple.com/source/Kerberos/Kerberos-47/KerberosFramework/Kerberos5/Sources/util/windows/getopt_long.c I think it's a matter of someone with a Windows compiler to just go over the code and build a small compatibility library. Can we first merge mingwport35 CWS, though? I suspect that would touch some of those files and I don't want to introduce conflicts to the Oracle updates just yet. Pedro.
RE: How to do with glibc-2.1.3 in AOOo?
Most stock implementations on Windows seem to have the original BSD license. However, I found one that should work at http://suacommunity.com/dictionary/getopt-entry.php. The getopt_source.zip has two files, getopt.h and getopt_long.c, and the getopt_long.c licenses are modified BSD (i.e., fully permissive and GPL compatible). The getopt.h license has the original BSD license, so don't use that. Use one that either has no license or is derived some other way. - Dennis -Original Message- From: Pedro F. Giffuni [mailto:giffu...@tutopia.com] Sent: Wednesday, September 14, 2011 11:23 To: ooo-dev@incubator.apache.org; dennis.hamil...@acm.org Cc: 'Michael Stahl' Subject: RE: How to do with glibc-2.1.3 in AOOo? Ahem ... Guys; --- On Wed, 9/14/11, Dennis E. Hamilton dennis.hamil...@acm.org wrote: ... If you list the functions you have in mind, and the names of the headers normally used to introduce their signatures, I will double-check the VC++ 2008 and VC++ 2010 libraries to see what the status is. We are far from being the only unixy port to Windows: A quick google for getopt_long Windows returns: http://opensource.apple.com/source/Kerberos/Kerberos-47/KerberosFramework/Kerberos5/Sources/util/windows/getopt_long.c I think it's a matter of someone with a Windows compiler to just go over the code and build a small compatibility library. Can we first merge mingwport35 CWS, though? I suspect that would touch some of those files and I don't want to introduce conflicts to the Oracle updates just yet. Pedro.
RE: How to do with glibc-2.1.3 in AOOo?
On Wed, 14 Sep 2011 13:43:09 -0700, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Most stock implementations on Windows seem to have the original BSD license. Including MSVC in the search produces more specific results. Mesa uses OpenBSD's version which is a 2 clause BSD license. http://cgit.freedesktop.org/mesa/mesa/tree/src/getopt Readdir_r is here: http://code.google.com/p/dirent/ The getopt.h license has the original BSD license, so don't use that. Use one that either has no license or is derived some other way. FWIW; The BSDs have removed the advertisement clause but I have to say I never found it problematic, just another political stand from the FSF. It shouldn't be an issue for Apache and its LGPL/MPL compatible so it shouldn't be an issue for LO either. Cheers, Pedro. -Original Message- From: Pedro F. Giffuni Sent: Wednesday, September 14, 2011 11:23 To: ooo-dev@incubator.apache.org; Cc: 'Michael Stahl' Subject: RE: How to do with glibc-2.1.3 in AOOo? Ahem ... Guys; --- On Wed, 9/14/11, Dennis E. Hamilton dennis.hamil...@acm.org wrote: ... If you list the functions you have in mind, and the names of the headers normally used to introduce their signatures, I will double-check the VC++ 2008 and VC++ 2010 libraries to see what the status is. We are far from being the only unixy port to Windows: A quick google for getopt_long Windows returns: http://opensource.apple.com/source/Kerberos/Kerberos-47/KerberosFramework/Kerberos5/Sources/util/windows/getopt_long.c I think it's a matter of someone with a Windows compiler to just go over the code and build a small compatibility library. Can we first merge mingwport35 CWS, though? I suspect that would touch some of those files and I don't want to introduce conflicts to the Oracle updates just yet. Pedro.
RE: How to do with glibc-2.1.3 in AOOo?
Apparently the getopt.h has been cleaned up in later OpenBSD, FreeBSD releases. The Todd Miller 2002 getopt_long.c version is the same, so that looks like a clear choice. Thanks, - Dennis -Original Message- From: Pedro Giffuni [mailto:giffu...@tutopia.com] Sent: Wednesday, September 14, 2011 14:09 To: dennis.hamil...@acm.org Cc: ooo-dev@incubator.apache.org Subject: RE: How to do with glibc-2.1.3 in AOOo? On Wed, 14 Sep 2011 13:43:09 -0700, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Most stock implementations on Windows seem to have the original BSD license. Including MSVC in the search produces more specific results. Mesa uses OpenBSD's version which is a 2 clause BSD license. http://cgit.freedesktop.org/mesa/mesa/tree/src/getopt Readdir_r is here: http://code.google.com/p/dirent/ The getopt.h license has the original BSD license, so don't use that. Use one that either has no license or is derived some other way. FWIW; The BSDs have removed the advertisement clause but I have to say I never found it problematic, just another political stand from the FSF. It shouldn't be an issue for Apache and its LGPL/MPL compatible so it shouldn't be an issue for LO either. Cheers, Pedro. -Original Message- From: Pedro F. Giffuni Sent: Wednesday, September 14, 2011 11:23 To: ooo-dev@incubator.apache.org; Cc: 'Michael Stahl' Subject: RE: How to do with glibc-2.1.3 in AOOo? Ahem ... Guys; --- On Wed, 9/14/11, Dennis E. Hamilton dennis.hamil...@acm.org wrote: ... If you list the functions you have in mind, and the names of the headers normally used to introduce their signatures, I will double-check the VC++ 2008 and VC++ 2010 libraries to see what the status is. We are far from being the only unixy port to Windows: A quick google for getopt_long Windows returns: http://opensource.apple.com/source/Kerberos/Kerberos-47/KerberosFramework/Kerberos5/Sources/util/windows/getopt_long.c I think it's a matter of someone with a Windows compiler to just go over the code and build a small compatibility library. Can we first merge mingwport35 CWS, though? I suspect that would touch some of those files and I don't want to introduce conflicts to the Oracle updates just yet. Pedro.
RE: How to do with glibc-2.1.3 in AOOo?
Backing up a little. I don't know if the original BSD license is a problem for Apache, but it becomes a problem downstream, so it is good to avoid having to carry that license and a NOTICE file about it around in Apache OOo. LESS RELEVANT: I've been looking for a good getopt( ) for my own use on some other projects, and the Todd Miller versions seems to be a good starting point. It is not what I would use, but I would use it as a compatibility check. Question: Is it always sufficient to be limited to char[] or would a w_char[ ] or even UTF-8 version be more suitable these days? Just curious. - Dennis -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Wednesday, September 14, 2011 14:37 To: ooo-dev@incubator.apache.org Subject: RE: How to do with glibc-2.1.3 in AOOo? Apparently the getopt.h has been cleaned up in later OpenBSD, FreeBSD releases. The Todd Miller 2002 getopt_long.c version is the same, so that looks like a clear choice. Thanks, - Dennis -Original Message- From: Pedro Giffuni [mailto:giffu...@tutopia.com] Sent: Wednesday, September 14, 2011 14:09 To: dennis.hamil...@acm.org Cc: ooo-dev@incubator.apache.org Subject: RE: How to do with glibc-2.1.3 in AOOo? On Wed, 14 Sep 2011 13:43:09 -0700, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Most stock implementations on Windows seem to have the original BSD license. Including MSVC in the search produces more specific results. Mesa uses OpenBSD's version which is a 2 clause BSD license. http://cgit.freedesktop.org/mesa/mesa/tree/src/getopt Readdir_r is here: http://code.google.com/p/dirent/ The getopt.h license has the original BSD license, so don't use that. Use one that either has no license or is derived some other way. FWIW; The BSDs have removed the advertisement clause but I have to say I never found it problematic, just another political stand from the FSF. It shouldn't be an issue for Apache and its LGPL/MPL compatible so it shouldn't be an issue for LO either. Cheers, Pedro. -Original Message- From: Pedro F. Giffuni Sent: Wednesday, September 14, 2011 11:23 To: ooo-dev@incubator.apache.org; Cc: 'Michael Stahl' Subject: RE: How to do with glibc-2.1.3 in AOOo? Ahem ... Guys; --- On Wed, 9/14/11, Dennis E. Hamilton dennis.hamil...@acm.org wrote: ... If you list the functions you have in mind, and the names of the headers normally used to introduce their signatures, I will double-check the VC++ 2008 and VC++ 2010 libraries to see what the status is. We are far from being the only unixy port to Windows: A quick google for getopt_long Windows returns: http://opensource.apple.com/source/Kerberos/Kerberos-47/KerberosFramework/Kerberos5/Sources/util/windows/getopt_long.c I think it's a matter of someone with a Windows compiler to just go over the code and build a small compatibility library. Can we first merge mingwport35 CWS, though? I suspect that would touch some of those files and I don't want to introduce conflicts to the Oracle updates just yet. Pedro.
RE: How to do with glibc-2.1.3 in AOOo?
--- On Wed, 9/14/11, Dennis E. Hamilton dennis.hamil...@acm.org wrote: .. Backing up a little. I don't know if the original BSD license is a problem for Apache, but it becomes a problem downstream, so it is good to avoid having to carry that license and a NOTICE file about it around in Apache OOo. Well, having both we obviously choose the less restricted. LESS RELEVANT: I've been looking for a good getopt( ) for my own use on some other projects, and the Todd Miller versions seems to be a good starting point. It is not what I would use, but I would use it as a compatibility check. If you want to use the standard version you should compare against this: http://pubs.opengroup.org/onlinepubs/009695399/functions/getopt.html of course you can customize it but then I'd suggest renaming it to something else. Question: Is it always sufficient to be limited to char[] or would a w_char[ ] or even UTF-8 version be more suitable these days? Just curious. For command line options I think the normal char is enough but if you have special needs I guess you can customize it. Again I would avoid namespace conflicts with libc. cheers, Pedro.
Re: How to do with glibc-2.1.3 in AOOo?
On Thu, 15 Sep 2011 08:06:40 +0300, Tor Lillqvist t...@iki.fi wrote: For command line options I think the normal char is enough I don't know what the OOo code actually uses getopt() for (I am pretty sure it is just some build-time tools that actually use it...), but you can be assured that the actual OOo executable(s), for Windows (which presumably *is* the OS you expect most of your users to have?), definitely do need the full original Unicode command line. (Remember that Windows is Unicode-based, all file names and other system interfaces are in UTF-16.) And of course the OOo code itself uses UTF-16 strings almost exclusively. Indeed, I had forgotten: http://dvice.com/archives/2009/01/klingon_keyboar.php :) Cheers, Pedro.
