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 <[email protected]> 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 < > [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 > >>> > >> > >> > > >
