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
[GitHub] [openoffice] ardovm opened a new pull request, #176: Compatibility with GNU Make 4.4 (slideshow module)
ardovm opened a new pull request, #176: URL: https://github.com/apache/openoffice/pull/176 Make 4.4 seems to ignore the parameters given for object slideshowimpl for static library "sldshw_s". We request the object file here too, so we indicate the parameters (again) here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: GNU make 4.4 under Cygwin64
Dear All, On Sun, Mar 12, 2023 at 12:01:01AM +0100, Arrigo Marchiori wrote: > Hello Matthias, All, > > apparently, compatibility with the latest GNU Make is not yet ensured. > > On Tue, Dec 06, 2022 at 01:20:17PM +0100, Matthias Seidel wrote: > > > And in the end it doesn't build: > > > > --- > > > > = > > Building module slideshow > > = > > > > Entering /cygdrive/c/Source/openoffice/main/slideshow/prj > > > > cd .. && make -s -r -j1 && make -s -r deliverlog > > [ build CXX ] slideshow/source/engine/slideshowimpl > > slideshowimpl.cxx > > c:/Source/openoffice/main/slideshow/source/engine/slideshowimpl.cxx(25) > > : fatal error C1083: Cannot open include file: > > 'precompiled_slideshow.hxx': No such file or directory > > make: *** No rule to make target > > '/cygdrive/c/Source/openoffice/main/solver/420/wntmsci12.pro/workdir/CxxObject/slideshow/source/engine/slideshowimpl.o', > > needed by > > '/cygdrive/c/Source/openoffice/main/solver/420/wntmsci12.pro/workdir/LinkTarget/StaticLibrary/sldshw_s.lib'. > > > > Stop. > > dmake: Error code 2, while making 'all' > [...] > > This seems to be a different problem than addressed with PR #175. > > The slideshow module seems to fail because the slideshowimpl.cxx file > is not provided the correct include path. > > There are two Makefiles, inside module slideshow, where the > slideshowimpl "object" is listed: > > - StaticLibrary_sldshw_s.mk: that contains the proper build >parameters passed to: > * gb_StaticLibrary_add_api, > * gb_StaticLibrary_set_include. > > - Library_slideshow.mk that does not list any of the above. > > If I add to the second file the calls to gb_Library_add_api and > gb_Library_set_include, with the same parameters as the static library > counterparts, then the compilation seems to be successful. > > If the above is not clear, I can open a PR proposing the above edits. PR just opened: https://github.com/apache/openoffice/pull/176 It builds now, but I am not sure this is the correct solution for this problem. > But the question is: why is the same "object" "slideshowimpl" listed > in two files? The second has a comment stating: > > # List this file again, even though it's in the static lib, so that > # component_getFactory and component_getImplementationEnvironment are > exported: > [...] Best regards, -- Arrigo - 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
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 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
