Apparently I left out that IDL file in my last commit. Sorry. The latest SVN should build now.
On Wed, Nov 8, 2017 at 6:41 PM, Damjan Jovanovic <dam...@apache.org> wrote: > Thank you. There is nothing in that log but "Error 1". > > It builds perfectly on FreeBSD. I'll try a Windows build too but it could > take a while. > > The file has *nix style line endings like every other IDL file. > > Any other ideas? > > Regards > Damjan > > > On Wed, Nov 8, 2017 at 5:50 PM, Matthias Seidel < > matthias.sei...@hamburg.de> wrote: > >> Hi Damjan, >> >> I was able to force the Windows buildbot and this is the detailed error >> log: >> >> https://ci.apache.org/projects/openoffice/buildlogs/win/ >> main/offapi/wntmsci12.pro/misc/logs/prj.txt >> >> Regards, Matthias >> >> >> Am 08.11.2017 um 14:36 schrieb Damjan Jovanovic: >> > 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 < >> matthias.sei...@hamburg.de> >> > 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/ParameterSu >> bstitution.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 >> >>> >> >> >> >> >> >> >> >
