Excuse me, after tried, I still did not know hot to build the source code for "x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni". What I have done is:
- ../gcc/configure --enable-core-jni --enable-languages=c,c++,java make all-target-libjava - also try "../gcc/configure && make", but get same result. - I also enable JNIDIRS in "x86_64-unknown-linux-gnu/libjava/classpath /native/jni/Makefile" manually, but still no effect. Welcome any ideas, suggestions or completions for it, thank. Also sorry, I did not finish sending patch v2 for it within 2014-08-03, one excuse is: for each complete building, it needs 12-15 hours under my laptop. So next, I shall buy a PC for it (also for linux kernel). Thanks. On 08/01/2014 01:19 PM, Chen Gang wrote: > > Sorry for no testsuite, I shall send patch v2 for it after finish > related testsuite within this week end (2014-08-03). > > And the patch v2 also need cc to java-patc...@gcc.gnu.org > > Thanks. > > On 07/31/2014 12:59 PM, Chen Gang wrote: >> >> >> On 07/31/2014 12:10 PM, Jeff Law wrote: >>> On 07/30/14 09:01, Chen Gang wrote: >>>> Hello All: >>>> >>>> I shall stop making this kind of patch, next. The reason is that I worry >>>> about what I have done have negative effect to others. And next, I shall >>>> try to send another kinds of patches for gcc when I have time. >>>> >>>> Many persons or companies use open source who never give thanks or >>>> contribution back to open source. But open source (especially, >>>> fundamental software) still provide common contributions to outside. >>>> >>>> What I have done is only for contribution back to open source, so I can >>>> understand none-reply from open source (at least, it is not the excuse >>>> to let myself stop). But what I worry about is whether bother others. >>> I don't think you've have any kind of negative impact. GCC developers >>> tend to be a bit more conservative and try not to change code just for >>> the sake of changing code. Thus we tend to want to have a clearer >>> understanding of why a particular change needs to be made. >>> >>> It's also the case that we tend to look more closely at patches from >>> relatively new developers simply because we don't have a long history of >>> interactions that have built trust over time. >>> >>> So, just to be clear, I don't think you're bothering anyone and I would >>> recommend you continue to analyze code and send patches. >>> >> >> OK, thank you for your encouragement. And I shall continue to send this >> kind of patches. >> >>> And sorry for telling you everything goes to gcc-patches. I often >>> forget there's a separate java patch list -- and more generally for the >>> runtime libraries, we're often a downstream code consumer. Thus a >>> proposed change in some of the runtime libraries may need to be sent to >>> other projects (Classpath is a good example). >>> >> >> OK, and I shall notice about it next time (send related patches to >> correct mailing list). >> >> For me, it will be good idea to have a related document for these >> mailing list intruduction (maybe it has, and I shall try to find it). >> >> >> Thanks. >> > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
