Tim, I see you have modified jdktools build a lot. Now it uses classlibs's make scripts to build native code, rather then jdktools's ones. Good consequence is that jdktools build now supports freebsd and apple platforms. But jdktools build now depends on the build settings in classlib's build. I think it's OK in general, but this exposed a few problems.
After the latest changes, there is a problem with using JPDA binaries built with old gcc 3.3.3 on linux/x86 (SLES9), which are not reproduced for GCC 4.0. JPDA is written in C++ and using C++ exceptions leads to VM crash. Adding -fpic solves this problem for GCC 3.3.3. I'm not sure if any classlib modules are written in C++. But using -fpic on linux/x86 is safe and can be added to classlib's make scripts to resolve problems with jdktools modules. The other minor problem is that classlib's make scripts don't define NDEBUG macro for release mode, so all debug/trace code is included into release build. This also should be fixed. If nobody objects to such modification of classlib's builds, I'll submit JIRA and provide patch. Thanks. Ivan On 5/3/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
Vladimir Ivanov wrote: > On 5/3/07, Tim Ellison <[EMAIL PROTECTED]> wrote: >> Vladimir Ivanov wrote: >>> And funny thing: when I remove tools module manually no 'java' file in >>> the 'bin' directory after the build. >> >> I don't understand what you mean here. > > Just: no launcher to run tests. Ok, I just put it back. Note that if you now update a workspace that had the launcher in LUNI already, and you didn't update to remove it, the fact that is has now come back will likely confuse SVN, and you will get an "object of the same name already exists" error. You can just remove modules/luni/src/main/native/launcher/ and update again. Regards, Tim
