Hi Matthias Was it a clean rebuild?
Can you post the full output of "build --from offapi"? Maybe it needs DOS line endings in ParameterSubstitution.idl? Damjan On Wed, Nov 8, 2017 at 2:52 PM, Matthias Seidel <[email protected]> wrote: > Hi Damjan, > > On my release machine (Win 10) it stops with: > > --- > make: *** [C:/Source/aoo/main/solenv/gbuild/UnoApiTarget.mk:165: > /cygdrive/c/Source/aoo/main/solver/420/wntmsci12.pro/ > workdir/UnoApiPartTarget/offapi/com/sun/star/sdb/ParameterSubstitution.urd > ] > Error 1 > make: *** Waiting for unfinished jobs.... > dmake: Error code 2, while making 'all' > > 1 module(s): > offapi > need(s) to be rebuilt > > Reason(s): > > ERROR: error 65280 occurred while making > /cygdrive/c/Source/aoo/main/offapi/prj > > When you have fixed the errors in that module you can resume the build > by running: > > build --from offapi > --- > > I will try to force a build on our buildbot to cross check. > > Regards, Matthias > > > Am 08.11.2017 um 05:34 schrieb Damjan Jovanovic: > > Hi > > > > As of revision 1814552, I've rewritten our formerly C++ based SDBC-JDBC > > bridge driver in Java. The SDBC-JDBC bridge is there to allows AOO to > > access databases through Java's JDBC drivers. > > > > This port originally aimed at fixing serious issues I discovered in the > old > > C++ implementation, where there is apparently memory corruption on method > > IDs that causes methods to be called on wrong Java objects. In the > process > > of porting I've also discovered and fixed many other problems. For > example: > > * The C++ code was calling Java code through the Java Invocation API, so > it > > was using strings to look up method names. This defeats type checking, > and > > in some cases was looking for methods with typos in their names or that > > don't even exist. My current bridge only uses Java to Java calls that are > > always strongly type checked and correct. > > * Conversions between bytes and chars were broken: n bytes were being > > copied verbatim into memory for char arrays n chars long in Java (Java's > > char is 16 bits) so the second half of the array was untouched and the > > first half had wrong chars, and non-existent classes like > > java.io.CharArrayInputStream were being created. Real classes that do > > exist, and proper character set conversions, are now used. > > * Chained Java exceptions are now converted to chained UNO exceptions via > > the commonly used and clearer getCause() chaining dimension, not the > > java.sql.SQLException's getNextException() chaining dimension. > > > > The new driver is, as seen externally, completely interchangeable with > the > > old one. Service names are identical, implementation names are identical, > > supported interfaces are identical, the configuration schema is > identical, > > initialization arguments are identical, even logging channels and > messages > > logged are identical - client code using the old driver should be able to > > use the new one transparently, and not only should everything that worked > > before still work now, but some things that didn't work before might also > > begin to work now. > > > > Having said that, the driver does push UNO to its limits, and might > reveal > > other bugs in UNO bridging, Base, other AOO components, and the C++ > runtime > > environment. I already discovered AOO sometimes crashes on FreeBSD due to > > issues in converting exceptions from Java to C++ (missing exception RTTI > > causes a segfault), but such bugs should be fixed in main/bridges and/or > > the Clang project. > > > > There are still some cleanups I want to do, like making sure nulls > strings > > are never passed or returned to UNO, cleaning up exception handling, > doing > > a comparison of every C++ method with every Java method to see if I > missed > > anything, and so on, which is why the old C++ code has been left in the > > tree for now even though it's no longer built. In the meanwhile, please > > feel free to start testing :). > > > > Oh and my original memory-corruption-induced IllegalClassChangeError is > > gone - my PostgreSQL SDBC driver already works better with the new > > SDBC-JDBC bridge :). > > > > Damjan > > > > >
