I have tried to compile OpenCascade on Win10 64bit, using VS2017. I compiled on 64bit, but I encounter a link errors, one of them is:
1>------ Build started: Project: TKDraw, Configuration: Debug x64 ------
1>LINK : fatal error LNK1104: cannot open file 'tcl86.lib'
========== Build: 0 succeeded, 9 failed, 50 up-to-date, 1 skipped ==========
I noticed that in project TKDraw, I have the following link settings files/path:
..\..\win64\vc14\libd\TKMesh.lib
..\..\win64\vc14\libd\TKService.lib
..\..\win64\vc14\libd\TKHLR.lib
C:\ActiveTcl\lib\tcl86t.lib
C:\ActiveTcl\lib\tk86t.lib
gdi32.lib
advapi32.lib
user32.lib
shell32.lib
..\..\win64\vc14\libd\TKShHealing.lib
opengl32.lib
windowscodecs.lib
C:\Program Files\freetype\lib\freetyped.lib
winmm.lib
..\..\win64\vc14\libd\TKTopAlgo.lib
..\..\win64\vc14\libd\TKGeomAlgo.lib
..\..\win64\vc14\libd\TKBRep.lib
..\..\win64\vc14\libd\TKGeomBase.lib
..\..\win64\vc14\libd\TKG3d.lib
..\..\win64\vc14\libd\TKG2d.lib
..\..\win64\vc14\libd\TKMath.lib
..\..\win64\vc14\libd\TKernel.lib
As you see, none of them tell me about tcl86.lib, but the compiler say that this lib is missing. Why ? Moreover, I didn't found any tcl86.lib in opencascade folder, so, why is asking me about this file ? Can you help me a little bit ?
You can download the 3rd party libraries for Open CASCADE here: https://old.opencascade.com/content/3rd-party-components
If you put all 3rd party libraries into one directory, you can state its location in the CMake build and the build will use them automatically.
This is because Visual Studio C++ compiler has a #pragma lib feature allowing to add library dependencies directly in C++ code, see src/Draw/Draw.cxx:
// on MSVC, use #pragma to define name of the Tcl library to link with,
// depending on Tcl version number
#ifdef _MSC_VER
// two helper macros are needed to convert version number macro to string literal
#define STRINGIZE1(a) #a
#define STRINGIZE2(a) STRINGIZE1(a)
#pragma comment (lib, "tcl" STRINGIZE2(TCL_MAJOR_VERSION) STRINGIZE2(TCL_MINOR_VERSION) ".lib")
#pragma comment (lib, "tk" STRINGIZE2(TCL_MAJOR_VERSION) STRINGIZE2(TCL_MINOR_VERSION) ".lib")
#undef STRINGIZE2
#undef STRINGIZE1
#endif
Apparently, your Tcl/Tk build has an extra suffix "t" in library file name tcl86t.lib, so that linker is unable to find tcl86.lib.
Possible solutions:
Rename tcl86t.lib -> tcl86.lib (the same for tk) in your Tcl installation.
Comment/remove pragma comment in OCCT source code. As you are using CMake, it seems all libraries are already specified via project settings.
Build Tcl/Tk from source code or use pre-built binaries without name deviations (as provided by OCCT project, for example).
I got the same error trying to compile SQLite from source with MSVC. I saw no #pragma references to tcl86.lib in the source. However, I copied tcl86.lib in the Tcl directory, and renamed it to tcl86t.lib. It seems to work.
In the SQLite crash8-1.2 test, I am getting error:
testfixture.exe: extra characters after close-quote while executing
"sqlite3_crashparams"
I hope it's just a test problem.
Also, the build process gives errors if there are blanks in any of the directory names where the SQLite source has been unzipped.
Related
whenever I generate my code with STM32cubeMX on Iar embedded workbench V8.5
this error is still present
Fatal Error [Pe035]: #error directive: "Unknown target."
The error is unrelated to either downloading or debugging. It is a build error.
The #error is a pre-processor directive in the code. If you double-click on one of those errors it will no doubt take you to the offending code. It is not possible from the image to direct you to the exact cause (you should post the "build Log" text in its entirety, rather then an image of the "build" tab), but will no doubt be code similar to (elided):
#if defined(STM32F405xx)
#include "stm32f405xx.h"
#elif defined(STM32F415xx)
#include "stm32f415xx.h"
#elif
...
#elif defined(STM32F423xx)
#include "stm32f423xx.h"
#else
#error "Unknown Target" <<<< HERE - no target macro has been defined.
#endif
The point being that the HAL code supports multiple STM32 variants and it is necessary to set a macro identifying your target so that the appropriate part specific code will be built.
If you created your project using STM32CubeMX or from the IAR IDE, there will be some place in the configuration where you can specify your target. (in the case of CubeMX I don't think you can do much of anything until you have selected the target). Failing that there will be some place to define command-line build macros in the build configuration.
I'm working with a proprietary code base where the owner would like users to get useful stack traces but not be able to view the source code. Generating Debian dbg packages with debug symbols but no source code is straightforward but the Redhat debuginfo RPMs are automatically created with source code.
Is there a way of configuring rpmbuild to build a debuginfo RPM without source code?
If not, what's the best way to remove the source code from a debuginfo package? Does anyone have a script to do it?
A -debuginfo package is just a sub-package, and can be created manually without source code. The automatic generation adds the necessary syntax to a spec file, but you can also do this manually, adding a debug info package in the spec file.
Disable automagic generation of *-debuginfo.rpm, run find-debuginfo.sh at the end of %install, and then remove the source files.
Another (and easier/cleaner) means to remove source files overrides this macro
%__debug_install_post \
%{_rpmconfigdir}/find-debuginfo.sh %{?_missing_build_ids_terminate_build:--strict-build-id} %{?_find_debuginfo_opts} "%{_builddir}/%{?buildsubdir}"\
%{nil}
in the spec file, replacing %{_rpmconfigdir}/find-debuginfo.sh with a modified/customized find-debuginfo.sh script.
Include the modified script in the spec file like
SourceN: my-find-debuginfo.sh
and then use the macro
%{SOURCEn}
(where N == n, some small appropriate integer) instead of the default to generate debugging symbols without source code.
Just finished a round of testing and in the end we inserted the following into the .spec file somewhere above the %description tag:
# Override the macro that invokes find-debuginfo.sh to remove
# the source files before the debuginfo pkg is assembled.
# It would be nice to remove the entire /usr/src tree but
# rpmbuild is running a check-files utility that fails the
# build if /usr/src/debug/%{name} isn't there. Tried to
# just delete the contents but it's tricky getting an
# asterisk to expand properly so we remove the entire
# directory and then restore an empty one. Sigh!
%define __debug_install_post \
%{_rpmconfigdir}/find-debuginfo.sh %{?_missing_build_ids_terminate_build:--strict-build-id} %{?_find_debuginfo_opts} "%{_builddir}/%{?buildsubdir}";\
rm -rf "${RPM_BUILD_ROOT}/usr/src/debug/%{name}"; \
mkdir "${RPM_BUILD_ROOT}/usr/src/debug/%{name}"; \
%{nil}
This works for RHEl 6 and 7 but results in a bash error in RHEl 5 so we avoid building a debuginfo package for the latter by not installing the redhat-rpm-config package.
We decided to avoid creating a modified find-debuginfo.sh script as suggested because there are already differences between different platforms and we preferred a single patch that would work for all targets including future new ones. This isn't perfect but is as close as we came up with.
CentOS 7 needed a slight modification of Guy's solution. Here's what I'm using successfully:
# Remove source code from debuginfo package.
%define __debug_install_post \
%{_rpmconfigdir}/find-debuginfo.sh %{?_missing_build_ids_terminate_build:--strict-build-id} %{?_find_debuginfo_opts} "%{_builddir}/%{?buildsubdir}"; \
rm -rf "${RPM_BUILD_ROOT}/usr/src/debug"; \
mkdir -p "${RPM_BUILD_ROOT}/usr/src/debug/%{name}-%{version}"; \
%{nil}
The following can be used to verify the source code is no longer contained within the RPM:
rpm -qpl xxx-debuginfo-1.0.0-1.el7.x86_64.rpm
For some time I am trying to create a static CHOLMOD lib from SuiteSparse Each other library (f.ex. Umfpack) can be easiy compiled from IDE (I used Code::Blocks on Linux and Visual Studio on Windows). However when trying to compile CHOLMOD I get bunch of syntax errors like:
t_cholmod_triplet.c(21): error C2061: syntax error : identifier 'TEMPLATE'
I investigated that there are some #defines missing (like PATTERN, REAL defines) and therefore those definitions of TEMPLATE are invisible. I searched for them in files and in makefiles but found nothing. However when typing make (on Linux) library compiles just fine. What am I missing?
You can use SuiteSparse METIS for Windows package: https://github.com/jlblancoc/suitesparse-metis-for-windows
Credit: Jose Luis Blanco (Universidad de Almeria); Jerome Esnault (INRIA).
Actually the problem exists because of "templates" created in C. It requires to recompile the same code multiple times with different flags. I have written the VS NMakefile based on the original makegile and it compiled it seamlessly.
I can't link properly to glew.
I have done:
#define GLEW_STATIC
#include "glew/glew.h"
#pragma comment(lib, "glew/glew32s.lib")
However, I still get the error:
LNK2019: unresolved external symbol __glewGenBuffersARB referenced in function initialize
Save yourself a lot of trouble and just put the glew.c file into your project. I never bother with linking to a glew library externally. Once you have that in there, the GLEW_STATIC macro will work. It's only one file, and (if this matters to you) it will carry nicely across platforms (rather than having to rebuild several OS-specific libs).
I want to extend the excellent #TheBuzzSaw's idea by providing a more detailed answer for a cmake project.
Download GLEW sources from here.
Unzip the archive and copy two files (src/glew.c and include/GL/glew.h) into your project's directory.
Edit glew.c so that the beginning of the file looks like this:
#ifndef GLEW_INCLUDE
#include "glew.h" /* Point to local glew.h file. */
#else
#include GLEW_INCLUDE
#endif
Use the following in your main.cpp file to include static GLEW correctly:
#define GLEW_STATIC
#include "glew.h"
To build the project, you must compile and link the static GLEW library. Sample CMakeLists.txt file with the use of copied files:
cmake_minimum_required(VERSION 3.17)
project(your-project-name)
add_library(STATIC_GLEW glew.c)
add_executable(your-project-name main.cpp)
target_link_libraries(your-project-name STATIC_GLEW)
Now, you should be able to build your project without any linking errors 🎉
This is my java file for which i wanted to generate a header file using javah for an android opencv application.
package com.hosa;
public class edgejava{
static{
System.loadLibrary("edgejava");
}
public native int main(``);
}
The generated header file is as below.
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class com_hosa_edgejava */
#ifndef _Included_com_hosa_edgejava
#define _Included_com_hosa_edgejava
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: com_hosa_edgejava
* Method: main
* Signature: ()I
*/
JNIEXPORT jint JNICALL Java_com_hosa_edgejava_main
(JNIEnv *, jobject);
#ifdef __cplusplus
}
#endif
#endif
the eclipse is pointing out that inclusion of jni.h in the header file is unresolved.
what are the steps to be taken to solve this????
regards,
srijith
I am having issues with this as well so for anyone that stumbles on this ...
I solved the JNI issue from eclipse - you may have already done step 1 or something similar
File -> New -> Other-> C++ > Convert to C++ Project
RIght Click on Project Head -> Properties -> C++ General -> Paths And Symbols
Add a path similar to this under GNU and GNUC++ Language Entries
/NDK/Platforms/Android-9/arch-arm/usr/include
Your path will be different dependent on how you are setup, which platform number etc.
Once done then rebuild the indexes when it prompts you
Close your project, re-open it, then clean-build (or it might happen immediately)
In my case the JNI.h was then found BUT the JNIEnv etc. were still unrecognized even though they are in the JNI.h file.
Also note for anyone having this issue it wont stop you from building, you just need to close the offending files, then open and close your project to get rid of the errors (what a pain)
UPDATE: FIXED!
In edition to the Above in Indigo do the following from the menu / dialog
Window->Preferences->C/C++->Index check the "Index Unused Headers" reindex/build if necessary
You might also need to add "/NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/lib/gcc/arm-linux-androideabi/4.4.3/include" above the include I mentioned above to the language entries.
All symbols are now recognized - Hope this helps someone it was driving me nuts.
FIXED!
Add to Application.mk:
APP_STL := gnustl_shared
Go to Properties -> C/C++ General -> Preprocessor Include-> Entries -> Add -> Include Directory -> File System Path, and select the path of the includes like:
${NDK_ROOT}\platforms\android-21\arch-arm\usr\include
${NDK_ROOT}\sources\cxx-stl\gnu-libstdc++\4.8\libs\armeabi-v7a\include
${NDK_ROOT}\sources\cxx-stl\gnu-libstdc++\4.8\include
${NDK_ROOT}\toolchains\arm-linux-androideabi-4.8\prebuilt\darwin-x86_64\lib\gcc\arm-linux-androideabi\4.8\include
!!! Check "Contains system headers" checkbox for each included path. !!!
Go to Properties -> C/C++ General -> Preprocessor Include-> Providers -> Check CDT GCC Built-in Compiler Settings -> OK
Clean and rebuild your project.
I had the same problem with Android JNI.
I fixed it by pointing the project to the include path of android jni.h in the NDK source
See how to download NDK from here:
https://developer.android.com/tools/sdk/ndk/index.html
Details about the fix is here:
Android Add Native support - unresolved jni.h, android/log.h etc
In my case, I just closed and open the project, then the errors disappeared.