I am trying to invoke an existing COBOL application using JNI. COBOL application structure is as follows.
c-wrapper(main)-->COBOLProgram -> several dyn(.so) and static called modules
The existing COBOL application involves several statically called subprograms(COBOL) and many dynamic(COBOL) ones.
Jni invocation of the application is ok, but it could not locate and invoke COBOL dynamic sub modules.
Modified Application structure (for jni) is as follows:
java class --> libjni.so --> appl.so
I verified COB_LIBRARY_PATH and LD_LIBRARY_PATH environment variables before the CALL, those seems to be fine.
Following error message got in the case dynamic modules.
libcob: ....<module>.so: undefined symbol: cob_save_call_params
I use 64 bit , 1.1.0 on linux. gcc is used to create binary using the c output of cobc command
This issue can be resolved by properly specifying -lcob linkage option(when using gcc). The gcc command used to create the binary already contained the option, but it was mistakenly placed in between target and source file, which was not in effect. Execution of dll without JNI invocation, somehow does not require -lcob option, but from the JNI invocation requires -lcob linkage option.
Related
I'm using SCons to build my project.
A third-party library I've integrated also uses SCons, but it can be updated from Git at any time and I've got no control over the contents of its SConstruct file.
When compiled on its own, the library's SConstruct file accepts the parameters bits=32/64 and target=debug/release
I tried building it with env.SConscript(), but this doesn't pass the parameters in a form that the target SConstruct file accepts (without using SCons' Import() function):
# Compile Godot-CPP, a wrapper library we depend on
if nuclex._is_debug_build(environment):
compile_godot_cpp = environment.SConscript(
'addons/godot-cpp/SConstruct', export='bits=64 target=debug'
)
else:
compile_godot_cpp = environment.SConscript(
'addons/godot-cpp/SConstruct', export='bits=64 target=release'
)
Can I compile another SConstruct file and pass parameters to it as if SCons had been invoked from the command line on its own?
I'm aware that I could just use env.Command() to start another SCons process, but then SCons couldn't parallelize the build (i.e. scons -j16) like it does in the case of env.SConscript().
There's not a good way to do this beyond Command().
You might ask the godot project if they could move the bulk of their logic into a SConscript at the top level which you could then import and somehow pass the needed parameters to.
I have simple question related to LIB command I have one sum.cpp file which contains one function add(int,int).
Now library name a.lib depends on sum.obj file and one another library name b.lib which depends upon a.lib and sum.obj
so scenario is
a.lib: sum.obj
b.lib : sum.obj a.lib
everything works fine but my doubt is why lib command not issuing duplicate warning or error.
We are using a PVS Studio (free variant for opensource projects) in conjunction with travis-ci and it for some reason spawns errors for files located in /usr/local/clang-3.5.0/lib/clang/3.5.0/include:
/usr/local/clang-3.5.0/lib/clang/3.5.0/include/stddef.h:58:1: warning: V677 Custom declaration of a standard 'size_t' type. The declaration from system header files should be used instead.
/usr/local/clang-3.5.0/lib/clang/3.5.0/include/stddef.h:86:1: warning: V677 Custom declaration of a standard 'wchar_t' type. The declaration from system header files should be used instead.
/usr/local/clang-3.5.0/lib/clang/3.5.0/include/stdarg.h:30:1: warning: V677 Custom declaration of a standard 'va_list' type. The declaration from system header files should be used instead.
/usr/local/clang-3.5.0/lib/clang/3.5.0/include/stddef.h:47:1: warning: V677 Custom declaration of a standard 'ptrdiff_t' type. The declaration from system header files should be used instead.
This location looks like an example of “system” headers for non-standard compiler and is far away from the project root (which AFAIR is somewhere in /home: standard travis location). Script run uses latest version from https://www.viva64.com/en/pvs-studio-download-linux/, latest run at “Mon Jul 3 20:13:42 UTC 2017” (unfortunately, used version is not saved).
If the compiler is located in some unusual place, it is recommended to add a new path to the analyzer exceptions, so that you can see in the report only the warnings for the code of your own projects.
pvs-studio-analyzer analyze ... -e /path/to/exclude-path ...
or
pvs-studio ... --exclude-path /path/to/exclude-path ...
It appears that PVS does not detect the error if clang is updated to clang-4.0.
I have a CMake setup to link together 4 static libraries and 1 shared one into a top level shared library (Let's call it Top.dll). This will work fine except for one thing. I have a module definition file that expresses which symbols should be public. Top.dll builds and so far so good.
Now when I try to link an executable with Top.dll via CMake I get linker errors for every public symbol claiming it is defined in two places (Top.dll and the static library in which it was actually defined) even though Top.dll contains no original definitions of its own. If I remove the static library then as expected I get unresolved symbol errors. If I remove the module definition file, I get the same. It seems like it is either there zero times or twice. Is there some setting I am missing here? I don't think I'm using CMake in a non-basic way...
UPDATE An explanation via CMake
# setup the lib
add_subdirectory(vendor/A) #shared library
add_subdirectory(vendor/B) #static library
add_subdirectory(vendor/C) #static library
add_library(Top SHARED ${ALL_SRC_FILES})
target_link_libraries(Top A B C)
set_target_properties(Top PROPERTIES LINK_FLAGS
"/def:${PROJECT_SOURCE_DIR}/definitions.def") #contains symbols from B
add_subdirectory(C/Tests)
# CMakeLists.txt from C/Tests
add_executable(Tests ${SRC_FILES})
target_link_libraries(Tests Top)
The above is simplified, but I will get errors like the following at the point that the C/tests project is compiled:
B.lib(xxx.obj) : error LNK2005: _ABC already defined in Top.lib(Top.dll)
If I remove B.lib from the target_link_libraries call, then as expected I get unresolved symbols. If I remove the /def line, same result.
I've been able to get around this by setting the target_link_libraries of B and C to private. This may or may not be the correct solution and I will wait for other answers. If I don't do this it appears that the dependency is carried up to the final executable (So it links to both Top.dll and B.lib, etc).
I'm doing low-level IO (for library bindings) in Haskell and am experiencing a segfault. I would like to use GHCi's :break to figure out what's going on, but here's what happens:
> import SDL
> :break SDL.setPaletteColors
cannot set breakpoint on setPaletteColors: module SDL.Video.Renderer is not interpreted
Since the offending code is not inside my own modules, but rather inside a module in an external package, it's loaded as compiled code and apparently I can't use :break on compiled modules.
GHCi manual confirms this and provides a hint:
There is one major restriction: breakpoints and single-stepping are only available in interpreted modules; compiled code is invisible to the debugger[5].
[5] Note that packages only contain compiled code, so debugging a package requires finding its source and loading that directly.
Let's try it directly:
> :load some_path/sdl2/src/SDL/Video/Renderer.hs
some_path/sdl2/src/SDL/Video/Renderer.hs:101:8:
Could not find module ‘Control.Monad.IO.Class’
It is a member of the hidden package ‘transformers-0.3.0.0’.
Perhaps you need to add ‘transformers’ to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
I can add the dependencies to my .cabal file, but this already feels wrong. Once I've done that:
> :load some_path/sdl2/src/SDL/Video/Renderer.hs
some_path/sdl2/src/SDL/Video/Renderer.hs:119:8:
Could not find module ‘SDL.Internal.Numbered’
it is a hidden module in the package ‘sdl2-2.0.0’
Use -v to see a list of the files searched for.
I could make those modules public (probably? by modifying the package .cabal?), but at this point it seems a really awkward way to do things and I didn't pursue it further.
EDIT:
I actually tried that and got the baffling result:
> :load some_path/sdl2/src/SDL/Video/Renderer.hs
[1 of 1] Compiling SDL.Video.Renderer ( some_path/sdl2/src/SDL/Video/Renderer.hs, interpreted )
Ok, modules loaded: SDL.Video.Renderer.
> :break SDL.setPaletteColors
cannot set breakpoint on SDL.setPaletteColors: module SDL.Video.Renderer is not interpreted
My (uneducated) guess: it's because the external module is still linked to my code as a binary, and loading it dynamically in interpreted mode doesn't change that.
So, to sum up the question: what is a good way to debug IO in an external package?
Additional notes:
I do have the source to the package I need to debug; in fact, it's been added to the project with cabal sandbox add-source
An alternative option to using GHCi would be to add traces to the package source, but this is an unfortunate option, since it involves recompilation of the package on each modification (whenever I need more information about the execution and modify the traces), and that takes a really long time. Interactive debugging with GHCi seems a better tool for this job, if only I knew how to use it.
Stack has some support for this. Running stack ghci --load-local-deps $TARGET will load your project and any dependencies that are in the packages field of stack.yaml, including if they're marked as extra-deps. Breakpoints will work then. You can debug a dependency in GHCi by running stack unpack $PACKAGE and adding it to packages in stack.yaml.
This is not a panacea however. If the packages have conflicting package-global language extensions (or other dynamic flags) or module name clashes it won't work. For example, if your top-level package has default-extensions: NoImplicitPrelude and your dependencies don't, they won't have a prelude imported and will almost certainly not load. See this GHC bug.