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
