Re: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v2]
On Fri, 28 Jan 2022 09:38:14 GMT, Christian Hagedorn wrote: > > > That's interesting. Is this implementation still around somewhere? I'm > > > glad that some of the mentioned things are not a problem anymore. > > > > > > Not I know. IIRC, it was based on DWARF 2. > > Okay, thanks. > > > > > * Different compiler (and different version of the same compiler) can > > > > generate DWARF with different version, may not be compatible with each > > > > other, as DWARF allows custom fields. > > > > * Maintenance cost to catch up DWARF spec/compiler changes. > > > > > > > > > That's indeed a problem of facing different DWARF versions. For this > > > parser, I tried to support the current default of GCC 10.x which is DWARF > > > 4. This standard was introduced in 2010 and is probably used by most > > > compilers nowadays at least (if not already DWARF 5 which was introduced > > > in 2017). However, even with GCC 10.x, it emitted DWARF 3 for one of the > > > sections (I'm not sure why) which I also needed to support - thus you can > > > never be sure. > > > DWARF 5 is still experimental for GCC 10.x and had some issues when I > > > tried that out back there - so I stayed away from implementing parsing > > > steps for it. But now with GCC 11.x, DWARF 5 seems to have become the > > > default. I might have to try out what's being emitted for HotSpot. But I > > > think for now, it is better to only focus on DWARF 4 instead of trying to > > > support various versions in one patch - we could still come back to that > > > later if it becomes widely used. Even if DWARF 5 is emitted, GCC could be > > > configured, for example, to emit DWARF 4 only which is probably an > > > acceptable workaround for testing environments. > > > > > > I think maintenance and test could be major pain points. Based on > > build.html, we can use gcc version anywhere between 5.0 and 10.2, it could > > be a challenge to ensure all supported version work correctly. > > I agree, that wide range is a problem and older GCC versions emitting older > DWARF version are not covered with this patch. If I parse a DWARF section > header with an unsupported version I will just bail out and it falls back to > the stack trace we are seeing today without source information. That's > probably fine for the scope of this patch. We could still come back and add > support for other missing versions. I see, it makes sense. Thanks! - PR: https://git.openjdk.java.net/jdk/pull/7126
Re: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v2]
On Thu, 27 Jan 2022 08:38:02 GMT, Christian Hagedorn wrote: > > Build changes look good. > > Thanks Erik! > > > Personally, I am in favor of this project. Actually, I were experimenting > > it with libdwarf. > > I would like to add some historical background on this topic, just for > > consideration. > > Thanks Zhengyu for sharing some background! > > > We had a dwarf parser over a decade ago, a little after elf parser, but > > never made to mainline. There were several reasons at the time. Good news, > > some are no longer applied today :-) > > That's interesting. Is this implementation still around somewhere? I'm glad > that some of the mentioned things are not a problem anymore. > Not I know. IIRC, it was based on DWARF 2. > > * Different compiler (and different version of the same compiler) can > > generate DWARF with different version, may not be compatible with each > > other, as DWARF allows custom fields. > > * Maintenance cost to catch up DWARF spec/compiler changes. > > That's indeed a problem of facing different DWARF versions. For this parser, > I tried to support the current default of GCC 10.x which is DWARF 4. This > standard was introduced in 2010 and is probably used by most compilers > nowadays at least (if not already DWARF 5 which was introduced in 2017). > However, even with GCC 10.x, it emitted DWARF 3 for one of the sections (I'm > not sure why) which I also needed to support - thus you can never be sure. > > DWARF 5 is still experimental for GCC 10.x and had some issues when I tried > that out back there - so I stayed away from implementing parsing steps for > it. But now with GCC 11.x, DWARF 5 seems to have become the default. I might > have to try out what's being emitted for HotSpot. But I think for now, it is > better to only focus on DWARF 4 instead of trying to support various versions > in one patch - we could still come back to that later if it becomes widely > used. Even if DWARF 5 is emitted, GCC could be configured, for example, to > emit DWARF 4 only which is probably an acceptable workaround for testing > environments. I think maintenance and test could be major pain points. Based on build.html, we can use gcc version anywhere between 5.0 and 10.2, it could be a challenge to ensure all supported version work correctly. - PR: https://git.openjdk.java.net/jdk/pull/7126
Re: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v2]
On Tue, 25 Jan 2022 15:10:11 GMT, Christian Hagedorn wrote: >> When printing the native stack trace on Linux (mostly done for hs_err >> files), it only prints the method with its parameters and a relative offset >> in the method: >> >> Stack: [0x7f6e01739000,0x7f6e0183a000], sp=0x7f6e01838110, >> free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, >> bool, DirectiveSet*)+0xec >> V [libjvm.so+0x8303ef] >> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, >> JavaThread*)+0x69 >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f >> >> This makes it sometimes difficult to see where exactly the methods were >> called from and sometimes almost impossible when there are multiple >> invocations of the same method within one method. >> >> This patch improves this by providing source information (filename + line >> number) to the native stack traces on Linux similar to what's already done >> on Windows (see >> [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): >> >> Stack: [0x7f34fca18000,0x7f34fcb19000], sp=0x7f34fcb17110, >> free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 >> (c1_Compilation.cpp:607) >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, >> bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) >> V [libjvm.so+0x8303ef] >> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 >> (compileBroker.cpp:2291) >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df >> (compileBroker.cpp:1966) >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, >> JavaThread*)+0x69 (compilerThread.cpp:59) >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d >> (thread.cpp:1297) >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f >> (os_linux.cpp:705) >> >> For Linux, we need to parse the debug symbols which are generated by GCC in >> DWARF - a standardized debugging format. This patch adds support for DWARF >> 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with >> x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still >> experimental and not generated for HotSpot. However, newer GCC version may >> soon generate DWARF 5 by default in which case this parser either needs to >> be extended or the build of HotSpot configured to only emit DWARF 4. >> >> The code follows the parsing steps described in the official DWARF 4 spec: >> https://dwarfstd.org/doc/DWARF4.pdf >> I added references to the corresponding sections throughout the code. >> However, I tried to explain the steps from the DWARF spec directly in the >> code (method names, comments etc.). This allows to follow the code without >> the need to actually deep dive into the spec. >> >> The comments at the `Dwarf` class in the `elf.hpp` file explain in more >> detail how a DWARF file is structured and how the parsing algorithm works to >> get to the filename and line number information. There are more class >> comments throughout the `elf.hpp` file about how different DWARF sections >> are structured and how the parsing algorithm needs to fetch the required >> information. Therefore, I will not repeat the exact workings of the >> algorithm here but refer to the code comments. I've tried to add as much >> information as possible to improve the readability. >> >> Generally, I've tried to stay away from adding any assertions as this code >> is almost always executed when already processing a VM error. Instead, the >> DWARF parser aims to just exit gracefully and possibly omit source >> information for a stack frame instead of risking to stop writing the hs_err >> file when an assertion would have failed. To debug failures, `-Xlog:dwarf` >> can be used with `info`, `debug` or `trace` which provides logging messages >> throughout parsing. >> >> **Testing:** >> Apart from manual testing, I've added two kinds of tests: >> - A JTreg test: Spawns new VMs to let them crash in various ways. The test >> reads the created hs_err files to check if the DWARF parsing could correctly >> find the filename and line number. For normal HotSpot files, I could not >> check against hardcoded
Re: RFR: JDK-8280583: Always build NMT [v3]
On Wed, 26 Jan 2022 08:36:44 GMT, Thomas Stuefe wrote: >> After discussing this on hotspot-runtime-dev [1], the general opinion seems >> to be that it would be worthwhile to get rid of INCLUDE_NMT and make NMT >> unconditional. This affects minimal builds only. As pointed out in the mail >> thread, the overhead is very small and it would get rid of one configuration >> to build and test. >> >> [1] >> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2022-January/053504.html >> >> Patch removes INCLUDE_NMT from hotspot, as well as dependent macros, as well >> as the associated build option. > > Thomas Stuefe has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains two commits: > > - fix copyrights > - remove INCLUDE_NMT and dependend code Good to me. - Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7213
Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v2]
On Mon, 2 Nov 2020 15:58:15 GMT, Coleen Phillimore wrote: >> This change turns the HashTable that JVMTI uses for object tagging into a >> regular Hotspot hashtable - the one in hashtable.hpp with resizing and >> rehashing. Instead of pointing directly to oops so that GC has to walk the >> table to follow oops and then to rehash the table, this table points to >> WeakHandle. GC walks the backing OopStorages concurrently. >> >> The hash function for the table is a hash of the lower 32 bits of the >> address. A flag is set during GC (gc_notification if in a safepoint, and >> through a call to JvmtiTagMap::needs_processing()) so that the table is >> rehashed at the next use. >> >> The gc_notification mechanism of weak oop processing is used to notify Jvmti >> to post ObjectFree events. In concurrent GCs there can be a window of time >> between weak oop marking where the oop is unmarked, so dead (the phantom >> load in peek returns NULL) but the gc_notification hasn't been done yet. In >> this window, a heap walk or GetObjectsWithTags call would not find an object >> before the ObjectFree event is posted. This is dealt with in two ways: >> >> 1. In the Heap walk, there's an unconditional table walk to post events if >> events are needed to post. >> 2. For GetObjectWithTags, if a dead oop is found in the table and posting is >> required, we use the VM thread to post the event. >> >> Event posting cannot be done in a JavaThread because the posting needs to be >> done while holding the table lock, so that the JvmtiEnv state doesn't change >> before posting is done. ObjectFree callbacks are limited in what they can >> do as per the JVMTI Specification. The allowed callbacks to the VM already >> have code to allow NonJava threads. >> >> To avoid rehashing, I also tried to use object->identity_hash() but this >> breaks because entries can be added to the table during heapwalk, where the >> objects use marking. The starting markWord is saved and restored. Adding a >> hashcode during this operation makes restoring the former markWord (locked, >> inflated, etc) too complicated. Plus we don't want all these objects to >> have hashcodes because locking operations after tagging would have to always >> use inflated locks. >> >> Much of this change is to remove serial weak oop processing for the >> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with >> jvmti code. >> >> It has also been tested with tier1-6. >> >> Thank you to Stefan, Erik and Kim for their help with this change. > > Coleen Phillimore has updated the pull request incrementally with one > additional commit since the last revision: > > Code review comments from StefanK. Shenandoah part looks good. - Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/967
Re: [8u] RFR: 8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal
Verified, it fixed build. Looks good to me.
Thanks for the quick fix.
-Zhengyu
On 9/9/20 2:16 PM, Severin Gehwolf wrote:
Hi,
Please review this 8u (jdk8u/jdk8u-dev tree) fix for JDK-8252395 that
I've pushed today. Thanks for Zhengyu Gu for noticing it. The pushed
fix added the java.debuginfo and unpack.debuginfo make targets on the
condition of ENABLE_DEBUG_SYMBOLS=true, which is insufficient. It needs
another check on POST_STRIP_CMD which is set to non-empty for --with-
native-debug-symbols={external,zipped}, and is indeed empty for --with-
native-debug-symbols=internal. For the --with-native-debug-symbols=none
case we have ENABLE_DEBUG_SYMBOLS=false.
Bug: https://bugs.openjdk.java.net/browse/JDK-8252975
webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252975/01/webrev/
Testing: Builds with
--with-native-debug-symbols={none,internal,external,zipped} on Linux x86_64
OK?
Thanks,
Severin
Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector
Hi Kim, - taskqueue.hpp has some small adjustments to enable subclassing Why this change instead of JDK-8204947? As the description from that RFE says: "The ShenandoahTaskTerminator from the Shenandoah project is a much better implementation of a task terminator.” We were busy on preparing Shenandoah for upstreaming, this did take a back seat. I am going to start to work on moving ShenandoahTaskTerminator to share tomorrow, but it should not hold up the review. Thanks, -Zhengyu
Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
Probably should also backport the followup RFE: https://bugs.openjdk.java.net/browse/JDK-8206183 Thanks, -Zhengyu On 09/11/2018 10:58 PM, David Holmes wrote: Or to be a little less obscure, this is a known issue and you should look into backporting: https://bugs.openjdk.java.net/browse/JDK-8205965 David On 12/09/2018 5:03 AM, Martin Buchholz wrote: https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m
Re: RFR: 8205091: AIX: build errors in hotspot after 8203641: Refactor String Deduplication into shared
Hi, Whatever the name you come up, could you please also update stringDedup.inline.hpp to use the same names? Thomas Schatzl pointed out the inconsistent, I made change to use S and Q, but apparently, I messed up in final patch. Otherwise, looks good to me too. -Zhengyu On 06/15/2018 06:36 AM, Thomas Stüfe wrote: Hi Matthias, Good catch. Patch for me is good if you guys agree on a good uncommon name. Gruß Thomas On Fri, Jun 15, 2018, 09:48 Baesken, Matthias wrote: Please review this small change that fixes the AIX build after "8203641: Refactor String Deduplication into shared". We are getting this compilation error : /build_ci_jdk_jdk_rs6000_64/src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp", line 107.38: 1540-0063 (S) The text "1" is unexpected. Looks like the name of the second template parameter (STAT) template static void initialize_impl(); is clashing with defines from the AIX system headers (where I find #define STAT 1 ) . Renaming STAT to something else fixes the build on AIX . Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8205091/ Bug : https://bugs.openjdk.java.net/browse/JDK-8205091 Thanks, Matthias
Re: Code Review Request: CR 6988099 Add version information to jvmti demos.
Hi Neil, My understanding is that you need to have at least two reviewers who have 'reviewer' privilege, (and I don't have 'reviewer' privilege). Yes, I am tied up, if you can handle the push, that will be great. What java bug id you need? can you use CR 6988099? BTW, here is the link to all the reviewers and committers: http://openjdk.java.net/census Thanks, -Zhengyu On 11/2/2011 1:37 PM, Neil Richards wrote: On Thu, 2011-10-20 at 09:21 -0700, Kelly O'Hair wrote: Looks good. -kto Hi Zhengyu, Given Kelly's blessing, are you now happy to push this change to jdk8? (If you're otherwise tied up, I can drive the mechanics of the push if you provide me with a suitable java bug id to use.) Regards, Neil
Re: Add version information to jvmti demos.
No progress been made. Any reason should be resolved right away? Thanks, -Zhengyu On 9/15/2011 2:50 AM, Sean Chou wrote: Hi, About this bug, is there any progressing ? 2011/6/8 Zhengyu Gu zhengyu...@oracle.com mailto:zhengyu...@oracle.com No, I did not make any progress on 6988099, as it was deferred to JDK8. With Dan's comment, looks good to me. Thanks, -Zhengyu On 6/7/2011 12:10 PM, Daniel D. Daugherty wrote: Adding Zhengyu since he is the RE on 6988099 and I'm not sure if he is on the serviceability-dev alias... Zhengyu, I don't know if you have a fix already in process for this issue or not. Comments on the Makefile change below. Dan On 6/6/2011 8:59 PM, David Holmes wrote: Sean, Because this is a JVMTI demo it falls under serviceability, so I've cc'ed that list. David Sean Chou said the following on 06/07/11 12:18: Is there any comment ? 2011/5/26 Sean Chou zho...@linux.vnet.ibm.com mailto:zho...@linux.vnet.ibm.com mailto:zho...@linux.vnet.ibm.com mailto:zho...@linux.vnet.ibm.com Hi all, I made a simple patch for bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988099 (jvmti demos missing Publisher (COMPANY resource) in dll and exe files on windows) .Will anyone have a look at my patch ? Thanks. diff --git make/common/Demo.gmk make/common/Demo.gmk index a3788ae..8c43cf9 100644 --- make/common/Demo.gmk +++ make/common/Demo.gmk @@ -158,6 +158,7 @@ ifneq ($(strip $(DEMO_ALL_NATIVE_SOURCES)),) # bit between them. LINK.demo = $(LINK.c) LDLIBS.demo = $(EXTRA_LIBS) $(LFLAGS_$(COMPILER_VERSION)) +DEMO_VERSION_INFO = $(OBJDIR)/$(LIBRARY).res else ifneq ($(DEMO_NEEDS_CPP),) LINK.demo = $(LINK.cpp) @@ -288,6 +289,13 @@ ifndef DEMO_SKIP_SRCZIP $(install-file) endif The change below is not bracketed by ifeq ($(PLATFORM),windows) but it certainly looks Windows specific. +# JDK name required here +RC_FLAGS += /D JDK_FNAME=$(LIBRARY).dll \ +/D JDK_INTERNAL_NAME=$(LIBRARY) \ +/D JDK_FTYPE=0x2L + + + # Native library building ifdef DEMO_LIBRARY @@ -308,8 +316,11 @@ $(OBJDIR)/%.$(OBJECT_SUFFIX): $(DEMO_BUILD_SRCDIR)/%.cpp # Actual creation of the native shared library (C++ and C are different) $(DEMO_LIBRARY): $(DEMO_FULL_OBJECTS) @$(prep-target) + ifeq ($(PLATFORM),windows) +$(RC) $(RC_FLAGS) $(CC_OBJECT_OUTPUT_FLAG)$(DEMO_VERSION_INFO) $(VERSIONINFO_RESOURCE) + endif $(LINK.demo) $(SHARED_LIBRARY_FLAG) $(CC_PROGRAM_OUTPUT_FLAG)$@ \ -$(DEMO_FULL_OBJECTS) $(LDLIBS.demo) +$(DEMO_FULL_OBJECTS) $(LDLIBS.demo) $(DEMO_VERSION_INFO) The above change uses $(DEMO_VERSION_INFO) but that variable is only set under ifeq ($(PLATFORM),windows) above. That won't break make, but I wanted to be sure that was intentional. @$(call binary_file_verification,$@) # Generation of any javah include file, make sure objects are dependent on it -- Best Regards, Sean Chou -- Best Regards, Sean Chou -- Best Regards, Sean Chou
Re: Add version information to jvmti demos.
Okay, once review is completed, I would help you to push to jdk8. Thanks, -Zhengyu On 9/15/2011 2:51 PM, Neil Richards wrote: On Thu, 2011-09-15 at 12:14 -0400, Zhengyu Gu wrote: No progress been made. Any reason should be resolved right away? Thanks, -Zhengyu On 9/15/2011 2:50 AM, Sean Chou wrote: Hi, About this bug, is there any progressing ? 2011/6/8 Zhengyu Guzhengyu...@oracle.com No, I did not make any progress on 6988099, as it was deferred to JDK8. With Dan's comment, looks good to me. Thanks, -Zhengyu I've made a couple of modifications to Sean's suggested change, in response to Dan's comments: * For Windows, added '$(DEMO_VERSION_INFO)' to 'LDLIBS.demo', so that the line of the link command doesn't need to be modified, and so 'DEMO_VERSION_INFO' isn't used outside a windows-specific context. * Wrapped the definition of 'RC_FLAGS' in a windows-specific block. I've uploaded the resulting webrev for your review and blessing [1]. If you're happy with change, I'll look to commit it up into jdk8/build/jdk Regards, Neil [1] http://cr.openjdk.java.net/~ngmr/6988099/webrev.00
Re: Add version information to jvmti demos.
No, I did not make any progress on 6988099, as it was deferred to JDK8. With Dan's comment, looks good to me. Thanks, -Zhengyu On 6/7/2011 12:10 PM, Daniel D. Daugherty wrote: Adding Zhengyu since he is the RE on 6988099 and I'm not sure if he is on the serviceability-dev alias... Zhengyu, I don't know if you have a fix already in process for this issue or not. Comments on the Makefile change below. Dan On 6/6/2011 8:59 PM, David Holmes wrote: Sean, Because this is a JVMTI demo it falls under serviceability, so I've cc'ed that list. David Sean Chou said the following on 06/07/11 12:18: Is there any comment ? 2011/5/26 Sean Chou zho...@linux.vnet.ibm.com mailto:zho...@linux.vnet.ibm.com Hi all, I made a simple patch for bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988099 (jvmti demos missing Publisher (COMPANY resource) in dll and exe files on windows) .Will anyone have a look at my patch ? Thanks. diff --git make/common/Demo.gmk make/common/Demo.gmk index a3788ae..8c43cf9 100644 --- make/common/Demo.gmk +++ make/common/Demo.gmk @@ -158,6 +158,7 @@ ifneq ($(strip $(DEMO_ALL_NATIVE_SOURCES)),) # bit between them. LINK.demo = $(LINK.c) LDLIBS.demo = $(EXTRA_LIBS) $(LFLAGS_$(COMPILER_VERSION)) +DEMO_VERSION_INFO = $(OBJDIR)/$(LIBRARY).res else ifneq ($(DEMO_NEEDS_CPP),) LINK.demo = $(LINK.cpp) @@ -288,6 +289,13 @@ ifndef DEMO_SKIP_SRCZIP $(install-file) endif The change below is not bracketed by ifeq ($(PLATFORM),windows) but it certainly looks Windows specific. +# JDK name required here +RC_FLAGS += /D JDK_FNAME=$(LIBRARY).dll \ +/D JDK_INTERNAL_NAME=$(LIBRARY) \ +/D JDK_FTYPE=0x2L + + + # Native library building ifdef DEMO_LIBRARY @@ -308,8 +316,11 @@ $(OBJDIR)/%.$(OBJECT_SUFFIX): $(DEMO_BUILD_SRCDIR)/%.cpp # Actual creation of the native shared library (C++ and C are different) $(DEMO_LIBRARY): $(DEMO_FULL_OBJECTS) @$(prep-target) + ifeq ($(PLATFORM),windows) +$(RC) $(RC_FLAGS) $(CC_OBJECT_OUTPUT_FLAG)$(DEMO_VERSION_INFO) $(VERSIONINFO_RESOURCE) + endif $(LINK.demo) $(SHARED_LIBRARY_FLAG) $(CC_PROGRAM_OUTPUT_FLAG)$@ \ -$(DEMO_FULL_OBJECTS) $(LDLIBS.demo) +$(DEMO_FULL_OBJECTS) $(LDLIBS.demo) $(DEMO_VERSION_INFO) The above change uses $(DEMO_VERSION_INFO) but that variable is only set under ifeq ($(PLATFORM),windows) above. That won't break make, but I wanted to be sure that was intentional. @$(call binary_file_verification,$@) # Generation of any javah include file, make sure objects are dependent on it -- Best Regards, Sean Chou -- Best Regards, Sean Chou
