Hi,
We have published two different snapshots for 32 bit Linux builds
with libstdc++.so.5 and so.6, but only so.6 snapshots with 64 bit
builds. I understand that this was a problem for a couple of users
using slightly older versions of gcc. so.5 and so.6 is more a toolset
and not a platform issue,
Ivan Popov wrote:
> Build scripts on Linux use CXXFLAGS instead of CFLAGS when compiling
> C++ code. Adding -fpic to CXXFLAGS solves the problem. It makes sense
> to set both variables to compile C and C++ sources in the same way.
> Here is the patch:
> I checked it on SLES9 with gcc 3.3.3 and now
Build scripts on Linux use CXXFLAGS instead of CFLAGS when compiling
C++ code. Adding -fpic to CXXFLAGS solves the problem. It makes sense
to set both variables to compile C and C++ sources in the same way.
Here is the patch:
Index: modules/jpda/src/main/native/jdwp/unix/transport/makefile
==
Guys,
it looks like we should add japitool check to our pre-milestone and
pre-release checks.
Because number of minor api compatibility errors has been introduced
to Harmony and has not fixed before M1 :(
You can see the M1 comparisions here:
Comparision between Harmony M1 and RI 1.5 (java and j
I'll check why local modification of CFLAGS does not work.
However, there is one more problem with running jdktools tests now. I
submitted HARMONY-3803 and provided patch. Could you please apply it.
Thanks.
Ivan
On 5/4/07, Ivan Popov <[EMAIL PROTECTED]> wrote:
It seems that local fix does not
It seems that local fix does not work, local settings for CFLAGS don't
affect final command line for gcc, so it still misses -fpic.
Thanks.
Ivan
On 5/4/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
Ivan Popov wrote:
>> Can you try this patch in working_jdktools/modules/jpda/src/ and let me
>> know
On 5/4/07, Stuart Ballard wrote:
Hi,
I'm afraid I'm not going to be able to get a chance to look at this
for a couple of weeks as I'm about to leave on vacation. There's a
chance I might be able to have a look at it while I'm gone but I don't
want to make any promises I might not be able to keep
Ivan Popov wrote:
>> Can you try this patch in working_jdktools/modules/jpda/src/ and let me
>> know if it fixes the problem:
>
> Yes, it should fix the problem locally (on 64-bit Linux it will
> produce two -fpic). But, I''d prefer to put it to common platform
> dependent settings for Linux/x86.
Mikhail Fursov wrote:
> My opinion here is the sooner we get switched to GCv5, the sooner we get it
> stable.
> So, I'm +1 to switch to GCv5 this month.
No objections here.
Regards,
Tim
Stepan Mishura wrote:
> On 5/3/07, Tim Ellison wrote:
>> Up until yesterday we had two copies of the launcher code, one in
>> classlib LUNI module, and one in jdktools. Hopefully we all agree that
>> we don't need two copies of the code.
>>
>> Yesterday I removed the launcher from classlib, and up
OK, what I should do if I want to use CLASSLIB+IBMVM?
If I should build HDK and replace VM after that I vote to have
launcher in CLASSLIB...
Thanks, Vladimir
On 5/4/07, Stepan Mishura <[EMAIL PROTECTED]> wrote:
On 5/3/07, Tim Ellison wrote:
> Up until yesterday we had two copies of the launche
On 5/3/07, Tim Ellison wrote:
Up until yesterday we had two copies of the launcher code, one in
classlib LUNI module, and one in jdktools. Hopefully we all agree that
we don't need two copies of the code.
Yesterday I removed the launcher from classlib, and updated the one in
jdktools; but that
My opinion here is the sooner we get switched to GCv5, the sooner we get it
stable.
So, I'm +1 to switch to GCv5 this month.
On 5/3/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
I think that it should, as well. But maybe the priorities are not the
same.
My suggestion would be to integrate GCv5
13 matches
Mail list logo
