Re: FreeBSD port status
Hi Don, Am 12.03.23 um 21:18 schrieb Don Lewis: > On 12 Mar, Matthias Seidel wrote: >> Hi Don, >> >> thank you for your detailed report! >> >> Most of the technical things are above my understanding. ;-) > Some of it is beyond mine, in particular the iterator stuff. I'm also very > unfamiliar with that part of the code and have no idea how to test it > properly. > >> But what I saw in the 4.1.14 development process was, that we have a big >> amount of code changes in trunk/AOO42X, that never got backported/released. > Yes. The code and build framework in trunk/AOO42X is much better than > AOO41X. > >> Normally, we should release it with AOO 4.2.0, but since that process is >> stagnating over years I would prefer to cherry-pick code into AOO41X >> (where possible). >> >> I already made some commits (mostly optical changes): >> >> https://github.com/apache/openoffice/compare/AOO4114-GA...AOO41X >> >> And maybe we can get AOO42X in a stable condition in parallel? > Trying to cherry-pick a lot of this stuff back into AOO41X would be a > lot of work. There are a lot of commits that would need to be > inventoried. There are also a lot of interdependencies, so the > cherry-picks would have to be done in the right order. Then there would > still likely be a bunch of merge conflicts that would need manual > intervention to resolve, with thie possibility of introducing bugs. That's why I wrote "where possible". Fact is that we need to have a branch available that can be released when needed. As long as we are able to release AOO42X. > > I see this as putting a lot of effort into something that is ultimately > a dead end. I think it would be better in the long run to get 4.2.0 out > the door. In Germany we say: "You run against open doors" ;-) If I only could be of help here... But the work on AOO42X should really be intensified. > > Something else that should be higher on the priority list is migrating > to a more modern Windows toolchain that has support for modern C. We > spent too much effort on working around the limitations of our current > Windows compiler when importing new versions of bundled third-party > code. Definitely! I think moving to a newer compiler is the first step we need to do on Windows. Again, I can not be of great help here but I will try to build everything that we have. Regards, Matthias > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: FreeBSD port status
> On 14 Mar 2023, at 12:06, Marcus wrote: > > Am 12.03.23 um 21:36 schrieb Don Lewis: >> FYI, I do maintain a FreeBSD port of AOO42X and periodically update it >> with newer snaphots of our code. FreeBSD users can install binary >> packages of it. It was broken for quite a while, but I've gotten it >> working again. > > it's great to see that you still maintain this port. Even when we don't call > it as official supported OS, it's one OS more where OpenOffice can run on. As a user of it - yes - awesome ! (And despite bork - not had a situation where some older version did not work on a current enough version). Dw - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: FreeBSD port status
Am 12.03.23 um 21:36 schrieb Don Lewis: FYI, I do maintain a FreeBSD port of AOO42X and periodically update it with newer snaphots of our code. FreeBSD users can install binary packages of it. It was broken for quite a while, but I've gotten it working again. it's great to see that you still maintain this port. Even when we don't call it as official supported OS, it's one OS more where OpenOffice can run on. Thanks for your work. :-) Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: FreeBSD port status
On 11 Mar, Don Lewis wrote: > I've had some time in the last couple of weeks to work on the FreeBSD > port. I was able to get 4.1.14 to build and updated the FreeBSD port to > that version. I committed the upgrade to the main branch of the FreeBSD > ports tree on March 8. I merged the change to the current ports > quarterly branch a short while ago, so mainstream users should see the > new binary packages show up in the next several days. > > For various reasons, I switched the FreeBSD port back to the bundled > boost. The FreeBSD port uses -std=gnu++98 mode to compile our code. One > of the things I found is that even in that mode, our bundled boost tries > to use some c++11 features, and recent versions of clang treat that as > an error. This can be fixed with a trivial patch, which I added to the > FreeBSD port. I plan to commit this fix to our source tree in the near > future. > > Another FreeBSD user found that our build is fragile, and can be broken > if the build environment is not clean. The problem is that the order of > the directories in our include path is not safe. We put the include > directories for external dependencies like the libs for gtk ahead of > internal and solver directories. If one of the system include > directories is /usr/local/include, then the build can pick up the system > boost if it is installed on the machine. The FreeBSD boost port has > issues with gnu++98 mode. This breaks both gbuild and dmake module > builds of 4.1.x. Gbuild is mostly fixed in trunk and 4.2.x, and on > those branches so much has been converted to gbuild that I haven't seen > the problem. The modules left using dmake don't seem to both use boost > and have problematic external dependencies. I have patches for both the > gbuild and dmake stuff, but the gbuild fix is only for the FreeBSD > platform. The dmake framework patch is generic, but I've only tested it > on FreeBSD. > > The FreeBSD port broke some time ago because of errors in some of the > API comments in the xmerge java source. We've fixed these in trunk and > 4.2.x, but they are still broken in 4.1.x. They have been flagged as > errors during the build for a very long time, but it was only sometime > last summer when they started getting treated as a fatal error by the > FreeBSD build. They are still flagged as errors, but they are no longer > fatal. I have no idea what caused the behavior to change in either > direction. > > I also experimented a bit with c++11 mode and discovered that recent > versions of clang are much less forgiving of questionable code in that > mode as compared to the older versions of clang that I tried several > years ago. I ran into many things that broke the build: > > reinterpret_cast< some_type*>(NULL) is a compilation error. These are > trivial to fix by switching to static_cast, but the modules where > these occur seem to use reinterpret_cast excessively. I would be > surpised if there were more than a handful of locations in our code > where reinterpret_cast is the right choice. > > Constructors where the width of the initialization data is wider than > the width of the member being initialized break the build. Recent > clang does not want to automatically narrow the data and wants an > explicit cast to be used. The casts are easy to add, but the compiler > is pointing out places in the code where there might be exploitable > integer overflows. Perhaps the member should be widened so that an > overflow isn't possible, or pehaps an assert should be added or an > exception thrown on overflow. It looks like Damjan fixed a bunch of this stuff back in January in a72d41dcd002e8c9b3d75696f0625302690e2d65 on trunk. I was working with AOO42X, which is why I didn't see the fixes. The narrowing fixes were done by adding casts, so any integer overflow issues are ignored, which is the status quo when compiled without the casts. > The canvas, dbaccess, reportdesign, and slideshow modules use > iterators such a ::std::find_if and ::std::count_if to repeatedly call > functions using ::boost::bind whose args are all supposed to be > references. In some instances the code uses ::boost::cref() to > convert expressions into references. Recent clang objects if the > argument to ::boost::cref() is not an lvalue. A handful are > trivivally fixable, but most are not. In some cases it is not obvious > if the value of the expression shouldn't be changing due to the > actions of the function in the previous iteration, so calculating the > expression once, storing the result in a temporary location and > passing a reference to that location could result in stale data being > used. In another case, a method is called that constructs a struct and > fills it with a bunch of data from multiple class member values, and > the struct is returned, a reference to that struct is created and that > reference passed to the function. It isn't obvious to me th
Re: FreeBSD port status
FYI, I do maintain a FreeBSD port of AOO42X and periodically update it with newer snaphots of our code. FreeBSD users can install binary packages of it. It was broken for quite a while, but I've gotten it working again. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: FreeBSD port status
On 12 Mar, Matthias Seidel wrote: > Hi Don, > > thank you for your detailed report! > > Most of the technical things are above my understanding. ;-) Some of it is beyond mine, in particular the iterator stuff. I'm also very unfamiliar with that part of the code and have no idea how to test it properly. > But what I saw in the 4.1.14 development process was, that we have a big > amount of code changes in trunk/AOO42X, that never got backported/released. Yes. The code and build framework in trunk/AOO42X is much better than AOO41X. > Normally, we should release it with AOO 4.2.0, but since that process is > stagnating over years I would prefer to cherry-pick code into AOO41X > (where possible). > > I already made some commits (mostly optical changes): > > https://github.com/apache/openoffice/compare/AOO4114-GA...AOO41X > > And maybe we can get AOO42X in a stable condition in parallel? Trying to cherry-pick a lot of this stuff back into AOO41X would be a lot of work. There are a lot of commits that would need to be inventoried. There are also a lot of interdependencies, so the cherry-picks would have to be done in the right order. Then there would still likely be a bunch of merge conflicts that would need manual intervention to resolve, with thie possibility of introducing bugs. I see this as putting a lot of effort into something that is ultimately a dead end. I think it would be better in the long run to get 4.2.0 out the door. Something else that should be higher on the priority list is migrating to a more modern Windows toolchain that has support for modern C. We spent too much effort on working around the limitations of our current Windows compiler when importing new versions of bundled third-party code. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: FreeBSD port status
Hi Don, thank you for your detailed report! Most of the technical things are above my understanding. ;-) But what I saw in the 4.1.14 development process was, that we have a big amount of code changes in trunk/AOO42X, that never got backported/released. Normally, we should release it with AOO 4.2.0, but since that process is stagnating over years I would prefer to cherry-pick code into AOO41X (where possible). I already made some commits (mostly optical changes): https://github.com/apache/openoffice/compare/AOO4114-GA...AOO41X And maybe we can get AOO42X in a stable condition in parallel? Regards, Matthias Am 12.03.23 um 08:47 schrieb Don Lewis: > I've had some time in the last couple of weeks to work on the FreeBSD > port. I was able to get 4.1.14 to build and updated the FreeBSD port to > that version. I committed the upgrade to the main branch of the FreeBSD > ports tree on March 8. I merged the change to the current ports > quarterly branch a short while ago, so mainstream users should see the > new binary packages show up in the next several days. > > For various reasons, I switched the FreeBSD port back to the bundled > boost. The FreeBSD port uses -std=gnu++98 mode to compile our code. One > of the things I found is that even in that mode, our bundled boost tries > to use some c++11 features, and recent versions of clang treat that as > an error. This can be fixed with a trivial patch, which I added to the > FreeBSD port. I plan to commit this fix to our source tree in the near > future. > > Another FreeBSD user found that our build is fragile, and can be broken > if the build environment is not clean. The problem is that the order of > the directories in our include path is not safe. We put the include > directories for external dependencies like the libs for gtk ahead of > internal and solver directories. If one of the system include > directories is /usr/local/include, then the build can pick up the system > boost if it is installed on the machine. The FreeBSD boost port has > issues with gnu++98 mode. This breaks both gbuild and dmake module > builds of 4.1.x. Gbuild is mostly fixed in trunk and 4.2.x, and on > those branches so much has been converted to gbuild that I haven't seen > the problem. The modules left using dmake don't seem to both use boost > and have problematic external dependencies. I have patches for both the > gbuild and dmake stuff, but the gbuild fix is only for the FreeBSD > platform. The dmake framework patch is generic, but I've only tested it > on FreeBSD. > > The FreeBSD port broke some time ago because of errors in some of the > API comments in the xmerge java source. We've fixed these in trunk and > 4.2.x, but they are still broken in 4.1.x. They have been flagged as > errors during the build for a very long time, but it was only sometime > last summer when they started getting treated as a fatal error by the > FreeBSD build. They are still flagged as errors, but they are no longer > fatal. I have no idea what caused the behavior to change in either > direction. > > I also experimented a bit with c++11 mode and discovered that recent > versions of clang are much less forgiving of questionable code in that > mode as compared to the older versions of clang that I tried several > years ago. I ran into many things that broke the build: > > reinterpret_cast< some_type*>(NULL) is a compilation error. These are > trivial to fix by switching to static_cast, but the modules where > these occur seem to use reinterpret_cast excessively. I would be > surpised if there were more than a handful of locations in our code > where reinterpret_cast is the right choice. > > Constructors where the width of the initialization data is wider than > the width of the member being initialized break the build. Recent > clang does not want to automatically narrow the data and wants an > explicit cast to be used. The casts are easy to add, but the compiler > is pointing out places in the code where there might be exploitable > integer overflows. Perhaps the member should be widened so that an > overflow isn't possible, or pehaps an assert should be added or an > exception thrown on overflow. > > The canvas, dbaccess, reportdesign, and slideshow modules use > iterators such a ::std::find_if and ::std::count_if to repeatedly call > functions using ::boost::bind whose args are all supposed to be > references. In some instances the code uses ::boost::cref() to > convert expressions into references. Recent clang objects if the > argument to ::boost::cref() is not an lvalue. A handful are > trivivally fixable, but most are not. In some cases it is not obvious > if the value of the expression shouldn't be changing due to the > actions of the function in the previous iteration, so calculating the > expression once, storing the result in a temporary location and > passing a reference to that location could result in stal
FreeBSD port status
I've had some time in the last couple of weeks to work on the FreeBSD port. I was able to get 4.1.14 to build and updated the FreeBSD port to that version. I committed the upgrade to the main branch of the FreeBSD ports tree on March 8. I merged the change to the current ports quarterly branch a short while ago, so mainstream users should see the new binary packages show up in the next several days. For various reasons, I switched the FreeBSD port back to the bundled boost. The FreeBSD port uses -std=gnu++98 mode to compile our code. One of the things I found is that even in that mode, our bundled boost tries to use some c++11 features, and recent versions of clang treat that as an error. This can be fixed with a trivial patch, which I added to the FreeBSD port. I plan to commit this fix to our source tree in the near future. Another FreeBSD user found that our build is fragile, and can be broken if the build environment is not clean. The problem is that the order of the directories in our include path is not safe. We put the include directories for external dependencies like the libs for gtk ahead of internal and solver directories. If one of the system include directories is /usr/local/include, then the build can pick up the system boost if it is installed on the machine. The FreeBSD boost port has issues with gnu++98 mode. This breaks both gbuild and dmake module builds of 4.1.x. Gbuild is mostly fixed in trunk and 4.2.x, and on those branches so much has been converted to gbuild that I haven't seen the problem. The modules left using dmake don't seem to both use boost and have problematic external dependencies. I have patches for both the gbuild and dmake stuff, but the gbuild fix is only for the FreeBSD platform. The dmake framework patch is generic, but I've only tested it on FreeBSD. The FreeBSD port broke some time ago because of errors in some of the API comments in the xmerge java source. We've fixed these in trunk and 4.2.x, but they are still broken in 4.1.x. They have been flagged as errors during the build for a very long time, but it was only sometime last summer when they started getting treated as a fatal error by the FreeBSD build. They are still flagged as errors, but they are no longer fatal. I have no idea what caused the behavior to change in either direction. I also experimented a bit with c++11 mode and discovered that recent versions of clang are much less forgiving of questionable code in that mode as compared to the older versions of clang that I tried several years ago. I ran into many things that broke the build: reinterpret_cast< some_type*>(NULL) is a compilation error. These are trivial to fix by switching to static_cast, but the modules where these occur seem to use reinterpret_cast excessively. I would be surpised if there were more than a handful of locations in our code where reinterpret_cast is the right choice. Constructors where the width of the initialization data is wider than the width of the member being initialized break the build. Recent clang does not want to automatically narrow the data and wants an explicit cast to be used. The casts are easy to add, but the compiler is pointing out places in the code where there might be exploitable integer overflows. Perhaps the member should be widened so that an overflow isn't possible, or pehaps an assert should be added or an exception thrown on overflow. The canvas, dbaccess, reportdesign, and slideshow modules use iterators such a ::std::find_if and ::std::count_if to repeatedly call functions using ::boost::bind whose args are all supposed to be references. In some instances the code uses ::boost::cref() to convert expressions into references. Recent clang objects if the argument to ::boost::cref() is not an lvalue. A handful are trivivally fixable, but most are not. In some cases it is not obvious if the value of the expression shouldn't be changing due to the actions of the function in the previous iteration, so calculating the expression once, storing the result in a temporary location and passing a reference to that location could result in stale data being used. In another case, a method is called that constructs a struct and fills it with a bunch of data from multiple class member values, and the struct is returned, a reference to that struct is created and that reference passed to the function. It isn't obvious to me that some of those class members are not modified by the function, so the stale data issue is there, but also the memory for the struct is leaked because it is never destroyed. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: FreeBSD port status
Am 01/15/2013 11:24 PM, schrieb Pedro Giffuni: Just a small update; The main set of patches for building on FreeBSD were committed before 3.4 Release. I have been slowly committing the remaining FreeBSD patches trying to avoid interfering with other platforms. All this work has been done by Maho. If someone notices breakage after Revision 1433680 (a one line removal), let me know so that it can be reverted. The only remaining issue to have a direct build from the sources is reported in Bugzilla i118574 and doesn't seem easy to solve cleanly. I have been updating some components to match what we use in FreeBSD, but the port is still fragile for two reasons: - internal icu. - stlport. The first needs to be updated and the second needs to die. Both issues are also key to get a working clang port and would help greatly MacOS X. In any case the status is ... the port works and has been shipping for a while! cheers, Pedro. Thats great news. Thanks a lot, Pedro and Maho, for your endless effort to support and keeping up-to-date this port on FreeBSD. Marcus
FreeBSD port status
Just a small update; The main set of patches for building on FreeBSD were committed before 3.4 Release. I have been slowly committing the remaining FreeBSD patches trying to avoid interfering with other platforms. All this work has been done by Maho. If someone notices breakage after Revision 1433680 (a one line removal), let me know so that it can be reverted. The only remaining issue to have a direct build from the sources is reported in Bugzilla i118574 and doesn't seem easy to solve cleanly. I have been updating some components to match what we use in FreeBSD, but the port is still fragile for two reasons: - internal icu. - stlport. The first needs to be updated and the second needs to die. Both issues are also key to get a working clang port and would help greatly MacOS X. In any case the status is ... the port works and has been shipping for a while! cheers, Pedro.
