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 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. Ditto here. His build fixes look a lot like mine, but the potential stale data and memory leak issues appear to remain. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
