Trying to build dcmtk with openssl - cmake

I'm trying to build dcmtk version 3.6.5 using the latest cmake GUI. I can build things fine if I don't include openssl support. When trying to build with openssl support, I get the following message:
Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.18363.
Performing Test OPENSSL_VERSION_CHECK
Performing Test OPENSSL_VERSION_CHECK - Success
Info: DCMTK OPENSSL support will be enabled
Info: DCMTK will compile with built-in (compiled-in) dictionary
Info: DCMTK will try to load external dictionary from default path on startup
Info: DCMTK's builtin private dictionary support will be disabled
Info: Thread support will be enabled
Info: Wide char file I/O functions will be enabled
Info: Wide char main function for command line tools will be disabled
Info: Building DCMTK without character set conversion support
CMake Error at CMake/CheckFunctionWithHeaderExists.cmake:16 (set):
Syntax error in cmake code at
C:/Users/SCHEFJX2/Desktop/DCMTK Conversion/3.6.5/dcmtk-3.6.5/CMake/CheckFunctionWithHeaderExists.cmake:17
when parsing string
-DLINK_LIBRARIES:STRING=${CMAKE_REQUIRED_LIBRARIES};crypt32;debug;C:\openssl-1.1.1i/lib/dcmtkssl_d.lib;optimized;C:\openssl-1.1.1i/lib/dcmtkssl_o.lib;debug;C:\openssl-1.1.1i/lib/dcmtkcrypto_d.lib;optimized;C:\openssl-1.1.1i/lib/dcmtkcrypto_o.lib
Invalid character escape '\o'.
Call Stack (most recent call first):
CMake/GenerateDCMTKConfigure.cmake:707 (CHECK_FUNCTIONWITHHEADER_EXISTS)
CMake/dcmtkPrepare.cmake:516 (include)
CMakeLists.txt:22 (include)
I set WITHOPENSSLINC to C:\openssl-1.1.1i
I copied openssl 1.1.1 from the dcmtk 3.6.6 directory to C:\openssl-1.1.1i (I have the 3.6.6 version but I'm not allowed to use it)
Other information:
Windows 10
Visual Studio 2017
Any suggestions?

Whoever decided that there should be two types of slashes acceptable for directory specifications and that not all programs would support both, is hopefully roasting in hell.
The problem is that WITHOPENSSLINC must use the forward slash and not the backslash.
Problem solved

Related

Gradle build doing nothing on WSL

I'm writing a Kotlin program, and using Gradle as the build system, as is customary in that language. I usually work on Windows, but it's time to start testing on Linux, so using WSL for that. Installed Gradle, cloned a copy of my code in WSL...
(base) a#DESKTOP-4B7M920:~/ayane$ gradle -version
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedClass (file:/usr/share/java/groovy-all.jar) to method java.lang.Object.finalize()
WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedClass
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
------------------------------------------------------------
Gradle 4.4.1
------------------------------------------------------------
Build time: 2012-12-21 00:00:00 UTC
Revision: none
Groovy: 2.4.16
Ant: Apache Ant(TM) version 1.10.5 compiled on March 28 2019
JVM: 11.0.7 (Ubuntu 11.0.7+10-post-Ubuntu-2ubuntu218.04)
So far so good, that warning happens sometimes, doesn't seem to portend immediate trouble.
This is my build file, that works on Windows:
(base) a#DESKTOP-4B7M920:~/ayane$ cat build.gradle.kts
plugins {
kotlin("jvm") version "1.3.72"
}
repositories {
jcenter()
}
dependencies {
implementation(kotlin("stdlib"))
testImplementation("org.junit.jupiter:junit-jupiter:5.6.2")
}
tasks.test {
useJUnitPlatform()
testLogging {
events("passed", "skipped", "failed")
}
}
Here goes.
(base) a#DESKTOP-4B7M920:~/ayane$ gradle build
> Task :buildEnvironment
------------------------------------------------------------
Root project
------------------------------------------------------------
classpath
No dependencies
BUILD SUCCESSFUL in 0s
1 actionable task: 1 executed
<-------------> 0% WAITING
Uh? I could understand if it threw an error because some prerequisite or other was unavailable. But no error, just nothing? What's going on?
You are using the newest version at this time of the Kotlin plugin for Gradle (1.3.72). However, you are using a really old version of Gradle (4.4.1). As you can read from the Kotlin documentation:
The Kotlin Gradle plugin 1.3.72 works with Gradle 4.9 and later.
It is unfortunate that the plugin doesn't check for this and give a more proper error message instead of just silently doing nothing. I guess you could create an issue for Jetbrains on this if you like.
Just as has been mentioned in the comment to your question, I also highly recommend using the wrapper. It ensures that the project is built with a particular declared version of Gradle that you, the build author, has decided on. Otherwise, you will have to document how to set up the environment correctly, including what version of Gradle to install.
Same thing goes for Java: be sure to clearly document which version is required or supported.
As for building in WSL, the only issue I've ever had with it was a remote build cache not working. This was because I had configured Git to checkout with POSIX line endings (LF) for source files, whereas the cache were populated on a Windows machine using CRLF line endings). It doesn't sound like you are using that feature, but other than that, everything has been working fine for me in WSL.

Build Linux Kernel module with warning i2c_register_board_info undefined

I follow an example in kernel.org to write an i2c driver but unfortunately when i compile i got this warning
WARNING: "i2c_register_board_info" [/home/pi/builddriver/samplei2c/pn535.ko] undefined!
Although compile with 1 warning and no error, I cannot insmod module. this is error when insmod
insmod: ERROR: could not insert module pn535.ko: Invalid module format
My question is how to solve the warning above?, I think it make .ko file to be invalid. Here is my source code on
pastebin
thank for your help!
That is not possible in a kernel module simply because the function i2c_register_board_info is not exported from the kernel source tree to the kernel modules (built using obj-m targets). You can achieve this by building your driver within the kernel source tree using (obj-y targets).

JVM Crash Problematic Frame: Canonicalizer::do_If

Iam facing JVM Crash cosistently while enabling hotdeploy (USING below java options on starting up JAVA_OPTS -Xmx4096m -XX:MetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=crash -XX:ThreadStackSize=512 -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=5 -XX:NewRatio=2 -XX:+UnlockDiagnosticVMOptions -XX:-UseLoopPredicate -Xdebug -Xrunjdwp:transport=dt_socket,address=$DEBUG_PORT,server=y,suspend=n -XX:NewRatio=2 -Dspringloaded.synchronize=true JAVA_OPTS=`echo $JAVA_OPTS -Dspringloaded.synchronize=true -javaagent:springloaded-1.2.1.jar -noverify
)
Environment : JDK 1.8 U 66, RHEL 6.7
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007faee9a1e27c, pid=27208, tid=140379827795712
#
# JRE version: Java(TM) SE Runtime Environment (8.0_66-b17) (build 1.8.0_66-b17)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode linux-amd64 )
# Problematic frame:
# V [libjvm.so+0x35027c] Canonicalizer::do_If(If*)+0x1c
#
# Core dump written. Default location: core.27208
#
# An error report file with more information is saved as:
# hs_err_pid27208.log
# [ timer expired, abort... ]
I've noticed both -javaagent and -noverify in Java options list.
It looks like springloaded agent generates invalid bytecode, while the bytecode verification is explicitly turned off. No surprise, this may lead to unpredictable results including JVM crash.
This is not a JVM problem, but most likely a bug in springloaded agent. Try to remove -noverify option.
-XX:-TieredCompilation may also work around this particular problem, but don't expect application to work correctly if the bytecode fails to pass verification. It's better to stay away from the buggy agent libraries.
4.2.1 Crash in HotSpot Compiler Thread or Compiled Code
If the fatal error log indicates that the crash occurred in a compiler
thread, then it is possible (but not always the case) that you have
encountered a compiler bug. Similarly, if the crash is in compiled
code then it is possible that the compiler has generated incorrect
code.
In the case of the HotSpot Client VM (-client option), the compiler
thread appears in the error log as CompilerThread0. With the HotSpot
Server VM there are multiple compiler threads and these appear in the
error log file as CompilerThread0, CompilerThread1, and AdapterThread.
Below is a fragment of an error log for a compiler bug that was
encountered and fixed during the development of J2SE 5.0. The log file
shows that the HotSpot Server VM is used and the crash occurred in
CompilerThread1. In addition, the log file shows that the Current
CompileTask was the compilation of the java.lang.Thread.setPriority
method.
An unexpected error has been detected by HotSpot Virtual Machine:
:
Java VM: Java HotSpot(TM) Server VM (1.5-internal-debug mixed mode) :
--------------- T H R E A D ---------------
Current thread (0x001e9350): JavaThread "CompilerThread1" daemon
[_thread_in_vm, id=20]
Stack: [0xb2500000,0xb2580000), sp=0xb257e500, free space=505k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code) V [libjvm.so+0xc3b13c] :
Current CompileTask: opto: 11 java.lang.Thread.setPriority(I)V
(53 bytes)
--------------- P R O C E S S ---------------
Java Threads: ( => current thread ) 0x00229930 JavaThread "Low
Memory Detector" daemon [_thread_blocked, id=21]
=>0x001e9350 JavaThread "CompilerThread1" daemon [_thread_in_vm, id=20] :
In this case there are two potential workarounds:
The brute force approach: change the configuration so that the application is run with the -client option to specify the HotSpot
Client VM.
Assume that the bug only occurs during the compilation of the setPriority method and exclude this method from compilation.
The first approach (to use the -client option) might be trivial to
configure in some environments. In others, it might be more difficult
if the configuration is complex or if the command line to configure
the VM is not readily accessible. In general, switching from the
HotSpot Server VM to the HotSpot Client VM also reduces the peak
performance of an application. Depending on the environment, this
might be acceptable until the actual issue is diagnosed and fixed.
The second approach (exclude the method from compilation) requires
creating the file .hotspot_compiler in the working directory of the
application. Below is an example of this file:
exclude java/lang/Thread setPriority
In general the format of this file is exclude CLASS METHOD, where
CLASS is the class (fully qualified with the package name) and METHOD
is the name of the method. Constructor methods are specified as
and static initializers are specified as .
Note - The .hotspot_compiler file is an unsupported interface. It is
documented here solely for the purposes of troubleshooting and finding
a temporary workaround.
Once the application is restarted, the compiler will not attempt to
compile any of the methods listed as excluded in the .hotspot_compiler
file. In some cases this can provide temporary relief until the root
cause of the crash is diagnosed and the bug is fixed.
In order to verify that the HotSpot VM correctly located and processed
the .hotspot_compiler file that is shown in the example above, look
for the following log information at runtime. Note that the file name
separator is a dot, not a slash.
Excluding compile: java.lang.Thread::setPriority
Source
Agree with #apangin, In the program you are doing bytecode intrumentation (-agent) but specifies -noverify. When verification is turned off, you may end up such crashes.
You should not use -noverify or -Xverify:none during byte code intrumentation.
For those of you unfamiliar with bytecode verification, it is simply part of the JVM's classloading process that checks the code for certain dangerous and disallowed behavior. You can (but shouldn't) disable this protection on many JVMs by adding -Xverify:none or -noverify to the Java command line. https://blogs.oracle.com/buck/entry/never_disable_bytecode_verification_in

Trying to Use MSBuild SonarQube and unable to make it work

I have been using SonarQube for code analyzing at a basic level however now I would like to measure the code against FX-COP rules. Hence I am attempting to use MSBuild SonarQube scanner. I read the documentation thoroughly and have setup my project likewise however when I execute it gives me error.
Below is the extract from the log:
MSBuild SonarQube Runner Bootstrapper 1.0.2.0
Default properties file was found at C:\....\1c36691bf5270463\SonarQube.Analysis.xml
Loading analysis properties from C:\....\1c36691bf5270463\SonarQube.Analysis.xml
Pre-processing started.
Preparing working directories...
Checking for updates...
MSBuild SonarQube Runner Pre-processor 1.0.2.0
Loading analysis properties from C:\...\1c36691bf5270463\SonarQube.Analysis.xml
Updating build integration targets...
Fetching analysis configuration settings...
Generating rulesets...
Pre-processing succeeded.
Microsoft (R) Build Engine version 12.0.21005.1
[Microsoft .NET Framework, version 4.0.30319.34209]
Copyright (C) Microsoft Corporation. All rights reserved.
Building the projects in this solution one at a time. To enable parallel build,
please add the "/m" switch.
Build started 11/20/2015 1:46:41 PM.
Project "C:\Project1.sln" on node 1 (rebuild target(s)).
ValidateSolutionConfiguration:
Building solution configuration "Debug|Any CPU".
Build succeeded.
9 Warning(s)
0 Error(s)
Time Elapsed 00:01:07.86
MSBuild SonarQube Runner Bootstrapper 1.0.2.0
Default properties file was found at C:\...\1c36691bf5270463\SonarQube.Analysis.xml
Loading analysis properties from C:\...\1c36691bf5270463\SonarQube.Analysis.xml
Post-processing started.
MSBuild SonarQube Runner Post-processor 1.0.2.0 gives several warnings similar to one below:
WARNING: File is not under the project directory and cannot currently be analysed
by SonarQube.
File: C:\Users\...\AppData\Local\Temp\2\.NETFramework,Version=v4.0.AssemblyAttributes.cs,
project: C:\...\1c36691bf5270463\SOURCE\x\y.csproj**
Calling the sonar-runner:
SONAR_RUNNER_OPTS is not configured. Setting it to the default value of -Xmx1024m
C:\...\1c36691bf5270463\.sonarqube\bin\sonar-runner\bin\..
SonarQube Runner 2.4
Java 1.8.0_51 Oracle Corporation (64-bit)
Windows Server 2008 R2 6.1 amd64
SONAR_RUNNER_OPTS=-Xmx1024m
INFO: Error stacktraces are turned on.
INFO: Runner configuration file: C:\...\1c36691bf5270463\.sonarqube\bin\sonar-runner\bin\..\conf\sonar-runner.properties
INFO: Project configuration file: C:\TeamCity\buildAgent\work\1c36691bf5270463\.sonarqube\out\sonar-project.properties
INFO: Default locale: "en_US", source code encoding: "UTF-8"
INFO: Work directory: C:\...\1c36691bf5270463\.sonarqube\out\.sonar
INFO: SonarQube Server 5.1.1
13:47:51.150 INFO - Load global repositories
13:47:51.743 INFO - Load global repositories (done) | time=593ms
13:47:51.758 INFO - Server id: 20151120125423
13:47:51.758 INFO - User cache: C:\...\cache
13:47:51.758 INFO - Install plugins
13:47:51.836 INFO - Install JDBC driver
.
.
.
13:47:55.518 INFO - ------------- Scan file1
13:47:55.534 INFO - Load module settings
13:47:55.658 INFO - Load rules
13:47:56.017 INFO - Base dir: C:\...\1c36691bf5270463\SOURCE\xxx
13:47:56.017 INFO - Working dir: C:\...\1c36691bf5270463\.sonarqube\out\.sonar\AC1_AC1_497EBFF2-C710-4843-8263-F534AF803D3E
13:47:56.017 INFO - Source encoding: UTF-8, default locale: en_US
13:47:56.532 INFO - Quality profile for cs: Sonar way
13:48:00.635 INFO - Sensor org.sonar.plugins.csharp.CSharpFxCopProvider$CSharpFxCopSensor#73c82ec1
INFO: -----------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: -----------------------------------------------------------------
Total time: 10.156s
Final Memory: 16M/306M
INFO: -----------------------------------------------------------------
13:48:00.791 Creating a summary markdown file...
Press any key to continue . . .
You need to run all your commands in a Developer Command Prompt for Visual Studio 2013 or higher and:
use at least MSBuild 12.0
have .NET 4.5.2+ installed
You have this error because the FxCop Results are not generated.
Do you see in the MSBuild's logs, execution of FxCop? This is visible inside the RunCodeAnalysis section of MSBuild's logs.
You need to run this from command line and use the "-X" flag on your command, this will give you verbose debugging, I would highly reccomend doing the following for troubleshooting.
sonar-runner.exe <arg> <arg> -X > sonar-runnerLog.txt
Then read or dump that log back here. either way you'll know a lot more about what the actual problem is.
You can get Visual Studio Express 2013 (or 15) for free and both of those come with their respective developer command prompts.

Issues with running nunit-console.exe with Mono

I could make a dll for NUnit NUnit test under mono, but when I tried to run in with nunit-console.exe I get the following error message.
Runtime Environment -
OS Version: Unix 10.3.0.0
CLR Version: 2.0.50727.1433 ( 2.6.4 (tarball Thu Apr 22 13:24:33 MDT 2010) )
ProcessModel: Default DomainUsage: Single
Execution Runtime: mono-2.0
** (/Users/smcho/bin/NUnit-2.5.5.10112/bin/net-2.0/nunit-console.exe:36800): WARNING **: The following assembly referenced from /private/var/folders/m4/m4u1hmP+FHOQaiZbHj1UCk+++TI/-Tmp-/nunit20/ShadowCopyCache/36800_634111616836311880/Tests_-22323139/assembly/shadow/54274fc2/118e035c_45a94c9e_00000001/mut.dll could not be loaded:
Assembly: nunit.framework (assemblyref_index=1)
Version: 2.5.5.10112
Public Key: 96d09a1eb7f44a77
System error: Invalid argument
** (/Users/smcho/bin/NUnit-2.5.5.10112/bin/net-2.0/nunit-console.exe:36800): WARNING **: Could not load file or assembly 'nunit.framework, Version=2.5.5.10112, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77' or one of its dependencies.
What might be wrong? I have nunit.framework.dll under /Users/smcho/bin/NUnit-2.5.5.10112/bin/net-2.0/framework, but it doesn't seem to know about this.
This is another frustrating point about using NUnit in Mono. As far as I've been able to tell, you need to have all of those missing files (there will be more than just nunit.framework.dll) in the same directory as nunit-console.exe.
There might be a command line option either in mono or nunit-console.exe to specify another directory to search for missing DLLs -- I'm not sure. Barring that, you'll have to copy the missing DLLs into the same folder as nunit-console.exe, or you'll have to cd into the framework folder and use mono ../nunit-console.exe /path/to/my/tests.dll
Once nuget is installed, you can use it to install nunit.console like so:
(This is from my .circlci/config.yml file)
- run: mono --runtime=v4.0 nuget.exe install nunit.console
- run: msbuild MySolution.sln
- run: mono --runtime=v4.0 NUnit.ConsoleRunner.3.12.0/tools/nunit3-console.exe FirstModule.Tests/bin/Debug/FirstModule.Tests.dll
- run: mono --runtime=v4.0 NUnit.ConsoleRunner.3.12.0/tools/nunit3-console.exe SecondModule.Tests/bin/Debug/SecondModule.Tests.dll
The trick is to specify the entire path for the NUnit.ConsoleRunner and to watchout for the - changing into a . by version 3