I've built a fat jar of the tesseract basic example of 7.9 MB (see also this SO question). Now I want to shrink its size using ProGuard. Using this standard gradle task with the addition of keep 'class org.bytedeco.javacpp.** {*;}' and dontwarn 'org.bytedeco.javacpp.**' works just fine (7.6 MB jar size) but I get a lot of warnings when running the jar:
Warning: Loader.putMemberOffset(): java.lang.ClassNotFoundException: org.bytedeco.tesseract. ...
Warning: Loader.putMemberOffset(): java.lang.ClassNotFoundException: org.bytedeco.leptonica. ...
(following this guide leads to the same result).
I can prevent these warnings by keeping tesseract and leptonica too:
keep 'class org.bytedeco.tesseract.** {*;}'
keep 'class org.bytedeco.leptonica.** {*;}'
which results in a minimally larger jar (7.7 MB), but as the program seems to work OK with the warnings I was wondering if there's another way, e.g. by keeping not everything from org.bytedeco.
It's a really petty issue, but maybe there's an easy solution for it (the additional 0.1 MB is not a problem at all, just trying to get a little better understanding of javacpp, which is a really great library).
Related
SBT 0.13.1 and Scala 2.10.3.
We have implemented a plugin that sets the dependencyOverrides to standard artifact versions. My dependencyOverrides set is about 950 artifacts large. Not that we have all these dependencies but this is the standard versions people need to use.
After implementing the overrides, sbt update times (a reference project with 11 sub-projects) on Mac (Mac OS 10.7.5, Oracle JDK 1.7.0_45) jumped from ~30 seconds to ~140 seconds. The referenced artifacts are actually smaller as this gets rid of many duplicate artifacts of different versions.
I've run sbt under -Xprof to see what is the problem and found this major difference:
Before dependencyOverrides:
Compiled + native Method
3.2% 10 + 0 org.apache.ivy.core.module.id.ModuleRules.getRules
After dependencyOverrides:
Compiled + native Method
31.6% 136 + 2 org.apache.ivy.core.module.id.ModuleRules.getRules
Xprof doesn't give me invocation counts. But from a brief review of ModuleRules.getRules there seem to be not much complexity. That gives me a hint the invocation count may have skyrocketed. I'll have to use different profilers to get a better grip.
Unfortunately, Scala/SBT plugin for IntelliJ constantly causes a sbt resolve and the user experience is that much worse. I'd like to run this by others who may have run into this issue before or even know of a good way to fix it (short of diving into ivy code and figuring out the issue + modifying ivy code myself).
Thanks in advance for any input.
Has anyone successfully ported googleTest to a real time process in WindRiver 3.0 / VxWorks 6.6 ?
I am able to get gtest to build, but I get a few errors when linking. I can modify these specific sections of code, but that only produces run time errors.
here is what I'm seeing:
googleTest.so: undefined reference to isascii(int)'
googleTest.so: undefined reference togettimeofday'
googleTest.so: undefined reference to `strcasecmp'
I have 2 shared Libraries (.so): 1 for gtest and 1 for gtest_main. I have 1 RTP (real time process) where I have my test code.
Note:
To get googletest to compile in vxworks, I had to modify some of the Flags: Specifically:
GTEST_HAS_POSIX_RE - 0
GTEST_HAS_TR1_TUPLE - 0
GTEST_HAS_STREAM_REDIRECTION 0
Any insight or advice is much appreciated.
Turns out the way the Kernel was configured was incorrect.
To remedy the problem, I actually made a brand new kernel; keeping all of the default settings. This worked.
VxWorks is not yet supported by Google Test.
Also note that there may need to be certain changes made to the code to support the platform. For example, getClockTime may not exist and the code have to be altered to use a user defined method.
I think there is a unique solution based on your platform, target and sim; and your development environment. As well as versions of the tool (vxworks / wind-river etc).
Googletest does seem to be supported on vxworks7
https://github.com/Wind-River/vxworks7-google-test/blob/master/README.md
I have compiled it, and built a DKM, but at the moment it does not seem to be supporting any tests, so I am not sure what is going on there
I'm getting a "Compilation exited with code 134" when attempting to use the "LLVM Optimizing Compiler" switch for release iPhone builds, using MonoTouch 4.0.1.
I don't get much information from build output window at all - just:
"Compilation exited with code 134, command:"
MONO_PATH=(snip)/bin/iPhone/Release/LSiOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --llvm --aot=mtriple=armv7-darwin,nimt-trampolines=2048,full,static,asmonly,nodebug,llvm-path=/Developer/MonoTouch/LLVM/bin/,outfile=/var/folders/03/033pAAGuHgGkIy4CorbVV++++TI/-Tmp-/tmp38107451.tmp/Newtonsoft.Json.MonoTouch.dll.7.s "(snip)/bin/iPhone/Release/LSiOS.app/Newtonsoft.Json.MonoTouch.dll"
Mono Ahead of Time compiler - compiling assembly (snip)/mscorlib.dll
What is odd is that in earlier command lines, there is a correlation between the DLL mentioned in the arm-darwin-mono command line and what is the compiling, but in this case it says "mscorlib.dll".
Any thoughts?
I have found a few cases (googling and from bugzilla.xamarin.com) where the error code 134 is related to Mono.Linker being too aggressive (removing something that's needed).
This is easy to confirm by turning off the linker, i.e. "Don't link" in Linker Options. If the build works then you can try isolating the assembly where the linker makes a mistake.
E.g. add a "--linkskip=mscorlib" to the mtouch extra parameters and re-enable linking. This will link everything (Link All) or all SDK (Link SDK assemblies) except the assembly you selected (mscorlib in the example). That's only a workaround and a bug report should be filled so the issue can be fixed properly (and get you all the linker advantages).
However be warned that there are other issues sharing the same error code, like:
http://ios.xamarin.com/Documentation/Troubleshoot#Error_134.3a_mtouch_failed_with_the_following_message.3a
YMMV
mtouch does its native builds in parallel so the logs can be confusing, e.g. you can see a bit of assembly X output followed by some assembly Y output.
Reading the full log might help you (or us) to pinpoint the issue.
I was having the exact same problem Scolestock. My app would build fine until I enabled llvm, then it was "Compilation exited with code 134, command" when trying to build the 7s for the app itself.
I'm elated to say that after 2 days of painstakingly whittling my app down to the core problem, I was able to isolate the issue to the usage of embedded dictionaries such as:
Dictionary<enum, Dictionary<enum, value>>
I was able to fix this by defining a class for the embedded dictionary and using that instead:
public class MyDefinition : Dictionary<enum, value>
{
}
...
public Dictionary<enum, MyDefinition>
Not sure if this will help you, but hopefully it'll help some poor soul who decides to use embedded dictionaries and runs into my same problem.
This is what I'm doing:
extract contents of my JRE's rt.jar
extract src.zip of my JDK (same version)
Now, if I copy Runtime.java from the extracted src folder and compile it using javac.exe without any modifications and then put it in the extracted rt folder to finally put everything back in a jar file using jar.exe, everything works as expected. The JRE runs fine.
However, if I make the slightest change to Runtime.java and compile it and put it in rt.jar, the JRE crashes whenever I attempt to start it. This is an example of a slight change that causes the silent crash:
/** Don't let anyone else instantiate this class */
private Runtime() {
System.out.println("This is a test.");
}
Instead of:
/** Don't let anyone else instantiate this class */
private Runtime() {}
Could anyone tell me why this is causing my JRE to crash?
Thanks in advance.
It's possible that System.out has not been initialised at the time that the Runtime() constructor runs. Usually console output is not considered a "slight" change, but at the wrong time it can invoke way too much stuff that may not be set up at all yet.
You're doing this all wrong. You can't distribute that modified JRE for a start, so it is only useful inside your organization . Install a SecurityManager and don't grant your codebase any of the RuntimePermissions you're trying to protect against.
#Tom - I advise you NOT to try to do this:
You cannot distribute the modified rt.jar file without violating the Sun binary license.
Even if you did, you would not be allowed to call it Java.
As you are finding, there are lots of complications that arise when you make changes, particularly when those changes might interfere with the JVM's behind the scenes initialization. And when things blow up during initialization, the JVM often cannot report the problem in an intelligible way.
If you do succeed in making the modified rt.jar work for one JRE, there is no guarantee that the same hacks will work for a different version.
Nobody in their right mind would knowingly use a modified JVM (especially one modified by a third-party) in a production app.
EDIT : judging from your other questions, I guess you are trying to reverse engineer or modify some third party Java application with a custom launcher. If you provided more information on what you were really trying to do, we might be able to suggest the right way to do it ... rather than using "desperate measures" such as modifying the JRE.
That's pretty strange, as I did the same trick with many classes in rt.jar in past.
Can you provide us with the crashed process output?
We have a project for a client that is written in VB.NET. In one of the projects, we have about 100 modules, which are all VERY simple. They're extension methods that convert between object types. Here is a small snippet:
Public Module ScheduleExtensions
<System.Runtime.CompilerServices.Extension()> _
Public Function ToServicesData(ByVal source As Schedule) As ScheduleServicesData
If (source IsNot Nothing) Then
Dim target As New ScheduleServicesData
With target
.CenterId = source.CenterId
.EmployeeGuid = source.EmployeeGuid
.EndDateTime = source.EndDateTime
The problem is, this project alone takes 2+ minutes to build. I ran diskmon and filemon, and it doesn't access the file system while the build appears to hang. The CPU usage is also low during the majority of the execution. After about 2 minutes, the build finishes and there is disk and CPU activity. The problem can be reproduced on any machine (4 tried so far).
I went so far as to compile the project using the vbc command line, and the problem is there as well.
Is there something about VB.NET extension methods that lead to poor compile time? That is the only feature we're using that is more complex than looping/getting/setting, etc.
Performance problems that show no significant CPU or DISK activity are invariably related to Network waits, either network performance itself or, more likely, waiting for responses from Services on other systems. Now I do not see anything in the sample that should have that problem, so I must assume that the problem is coming from something else either in your project, or your project settings or your VS environment, or your system's environment.
You might try to get a tool that can monitor all network calls from your system and see what's going on.
It's hard to know what the problem would be based on a small sample like this. There is nothing inherently slow about extension method support in the compiler and we have numerous regression tests in this area. If there is a bug, it's likely a combination of several factors causing the problem.
If you have the time please file a bug on this issue at
http://connect.microsoft.com
It makes the bug much easier to investigate if you can provide a small sample which reproduces the problem.