I'm using Media Autobuild Suite to build a more comprehensive FFmpeg executable for Windows than what's available in binaries distributed online, but I've encountered issues. I've resolved errors in a couple libraries by skipping them (commenting them out in ffmpeg_options.txt), but I'm stuck on the GLSLang module (OpenGL Shader Language). I've already disabled it and OpenGL in ffmpeg_options.txt as well as other switches labeled "options that add shared dependencies," and the suite is still trying to build it.
Disabled options:
#--enable-fontconfig
#--enable-libmfx
#--enable-decklink
#--enable-librist
#--enable-librtmp
#--enable-libssh
#--enable-libtesseract
#--enable-vapoursynth
#--enable-liblensfun
#--enable-libglslang
#--enable-vulkan
#--enable-opencl
#--enable-opengl
#--enable-cuda-nvcc
#--enable-libnpp
#--enable-libopenh264
The failed build generates an entire folder of logs, but here's the error message that prints in the console:
Running git clone for glslang...
Running git update for glslang...
┌ glslang git ........................................ [Recently updated]
├ Running dependencies...
Likely error (tail of the failed operation logfile):
CPPFLAGS: -D_FORTIFY_SOURCE=0 -D__USE_MINGW_ANSI_STDIO=1
CFLAGS: -mthreads -mtune=generic -O2 -pipe
CXXFLAGS: -mthreads -mtune=generic -O2 -pipe
LDFLAGS: -pipe -static-libgcc -static-libstdc++
/usr/bin/python ./update_glslang_sources.py
/usr/bin/python: can't open file '/build/glslang-git/./update_glslang_sources.py': [Errno 2] No such file or directory
dependencies failed. Check C:/mab_suite/build/glslang-git/ab-suite.dependencies.log
This is required for other packages, so this script will exit.
Creating diagnostics file...
Attach C:\mab_suite\build\logs.zip to the GitHub issue.
Make sure the suite is up-to-date before reporting an issue. It might've been fixed already.
Try running the build again at a later time.
What modules/libraries do I have to fix or skip to prevent this error from causing the build to fail?
Related
everyone.
I'm try to build CPU2017 intrate and fprate test set on aarch64 server with gcc9.3. All the benchmark build successed, except 510.parest_r. Then i try build it with gcc9.4, meet the same error. I used the Example-gcc-linux-aarch64.cfg as configure file, just edit the gcc path.
Here is the failed info:
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/me-tomography/synthetic_data.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/me-tomography/synthetic_data.cc
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/multigrid/mg_base.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/multigrid/mg_base.cc
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/me-tomography/measurements.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/me-tomography/measurements.cc
init2.c:52: MPFR assertion failed: p >= 2 && p <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
during GIMPLE pass: forwprop
source/me-tomography/measurements.cc: In constructor 'METomography::Measurements::ReferencedMeasurements::RatioMinusRatio<dim, number>::RatioMinusRatio(const libparest::Slave::Stationary::ProblemDescription&, const dealii::Function<dim>&, const std::set<unsigned char>&) [with int dim = 3; number = double]':
source/me-tomography/measurements.cc:1739:7: internal compiler error: Aborted
1739 | RatioMinusRatio<dim,number>::
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
0xafbd97 crash_signal
../.././gcc/toplev.c:326
0xffff9e304d78 __GI_raise
../sysdeps/unix/sysv/linux/raise.c:51
0xffff9e2f1aab __GI_abort
/build/glibc-RIFKjK/glibc-2.31/stdlib/abort.c:79
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
specmake: *** [/home/spec/cpu2017_aarch64/benchspec/Makefile.defaults:356: source/me-tomography/measurements.o] Error 1
specmake: *** Waiting for unfinished jobs....
The failed info seem be caused by the MPRF float percision setting?
I tried build 510.parest_r with llvm-10, build success.
By the way, i build same gcc9.3 in x86_64 server, build 510.parest_r success.
You've found a bug in an older version of GCC (or possibly your system's RAM is failing, but unlikely if it consistently crashes at the same place). Or perhaps a bug in MPFR, although that seems less likely.
If you preprocess that source (add -E or -save-temps to the command line that crashed) and put it on https://godbolt.org/, does it still crash the same way with current ARM64 GCC, e.g. a nightly build of trunk? (https://godbolt.org/z/K6GnrYrj1 is ARM64 GCC trunk, with your command line args without the preprocessor stuff, which won't matter when compiling CPP output.)
If it still crashes with current GCC, then file a bug report on https://gcc.gnu.org/bugzilla/, ideally with a MCVE of the part of the source that triggers the bug. (Remove as many parts of the file as you can while preserving the crash behaviour. e.g. take out tons of stuff, undo if that makes it compile.)
If it doesn't crash with newer GCC, it might already be a known bug, or got fixed by accident, or a different MPFR or other library version mattered. In that case, maybe not worth reporting it upstream. Or if you do make sure to include the fact that the range of affected versions doesn't include GCC12 or current trunk. Probably this Stack Overflow Q&A is sufficient for future users to know that it's a known bug.
I'm trying to build Google's Skia library on Mac, but when I try running
ninja -C out/Static/
in order to build the library, it gives me this error (after many, many similar errors):
[14/1073] compile ../../src/gpu/GrBackendTextureImageGenerator.cpp
FAILED: obj/src/gpu/gpu.GrBackendTextureImageGenerator.o
c++ -MD -MF obj/src/gpu/gpu.GrBackendTextureImageGenerator.o.d -DNDEBUG -DSK_ASSUME_GL=1 -DSK_ENABLE_API_AVAILABLE -DSK_GAMMA_APPLY_TO_A8 -DSKIA_IMPLEMENTATION=1 -DSK_GL -I../.. -Wno-attributes -fstrict-aliasing -fPIC -fvisibility=hidden -isysroot b\'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk\\n\' -O3 -Wno-sign-conversion -Wno-unused-parameter -std=c++17 -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -c ../../src/gpu/GrBackendTextureImageGenerator.cpp -o obj/src/gpu/gpu.GrBackendTextureImageGenerator.o
clang: warning: no such sysroot directory: 'b'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk\n'' [-Wmissing-sysroot]
In file included from ../../src/gpu/GrBackendTextureImageGenerator.cpp:8:
In file included from ../../include/gpu/GrContext.h:11:
In file included from ../../include/core/SkMatrix.h:11:
In file included from ../../include/core/SkRect.h:11:
In file included from ../../include/core/SkPoint.h:11:
In file included from ../../include/core/SkMath.h:11:
../../include/core/SkTypes.h:26:18: fatal error: 'TargetConditionals.h' file not found
#include "TargetConditionals.h"
^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
ninja: build stopped: subcommand failed.
It seems like the sysroot directory b'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk\n' is wrong, however "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk" does exist and "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/" has the file TargetConditionals.h.
I haven't used ninja before, but I tried looking in toolchain.ninja but could find no way to change the sysroot variable. I also reinstalled Xcode and Xcode command line tools, to no avail. Any help would be greatly appreciated!
I too struggled a lot. The solutions that I tried:
xcode-select --install for installing command line tools. But it used to say that command line tools are already installed.
Tried re-installing xcode to fix some linkage issue.
Tried a could of other solutions found on web.
Finally, what worked for me is by switching to python2. I had python2 and python3 installed. My path environment variable in .zshrc was giving precedence to python3. So, all internal scripts generated by ninja had python3 in precedence.
I temporarily removed python3, you can keep both but its precedence should be changed. Then regenerate build directory using gn. Then use ninja to build.
Note:
clang: warning: no such sysroot directory: 'b'/Applications/ : Here 'b' use to represent that string literal should be treated as byte literal in python3. So that could be the cause.
Background
I'm compiling, on a machine which runs macOS 10.15, a project which ships an old version of libpng (1.6.17) as a submodule. The corresponding code is available at https://github.com/glennrp/libpng. I also have libpng 1.6.37 installed by Homebrew.
Until not so long ago, I was able to compile libpng 1.6.17 using CMake without trouble. Since very recently (but the exact date is unknown to me), build fails with errors like:
FAILED: CMakeFiles/png16_static.dir/pngwutil.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -I/usr/local/include -I. -I../ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -MD -MT CMakeFiles/png16_static.dir/pngwutil.o -MF CMakeFiles/png16_static.dir/pngwutil.o.d -o CMakeFiles/png16_static.dir/pngwutil.o -c ../pngwutil.c
../pngwutil.c:2413:20: error: use of undeclared identifier 'PNG_WEIGHT_SHIFT'
PNG_WEIGHT_SHIFT;
^
I ran a few checks against a copy of my project I had which still compiled correctly because CMake wasn't re-running itself on it. The only difference between the two cases is a -I/usr/local/include flag added to compiler calls (I added some markup to help see the difference):
suceeds:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -Dpng16_EXPORTS -Iext_build/libpng -I../../ext/libpng -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -fPIC -fno-stack-protector -fomit-frame-pointer -fno-math-errno -ffp-contract=fast -march=native -MD -MT ext_build/libpng/CMakeFiles/png16.dir/pngrio.o -MF ext_build/libpng/CMakeFiles/png16.dir/pngrio.o.d -o ext_build/libpng/CMakeFiles/png16.dir/pngrio.o -c ../../ext/libpng/pngrio.c
<---------------------------------->
fails:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -Dpng16_EXPORTS -I/usr/local/include -Iext_build/libpng -I../../ext/libpng -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -fPIC -fno-stack-protector -fomit-frame-pointer -fno-math-errno -ffp-contract=fast -march=native -MD -MT ext_build/libpng/CMakeFiles/png16.dir/pngrio.o -MF ext_build/libpng/CMakeFiles/png16.dir/pngrio.o.d -o ext_build/libpng/CMakeFiles/png16.dir/pngrio.o -c ../../ext/libpng/pngrio.c
<------------------------------------------------------->
I re-ran CMake on the copy of the project which was working and I got the same error, which pointed me to a system-related problem. I then checked out directly the libpng sources and got the same error.
Steps to reproduce
Clone the libpng repo and check out v1.6.17
git clone https://github.com/glennrp/libpng.git
cd libpng
git checkout v1.6.17
Build libpng
cmake . -B build && cmake --build build
Question
What did add this -I/usr/local/include flag to my compiler calls?
Bonus question (maybe more interesting)
Now, it gets funny. If you checkout a more recent libpng (I tried with 1.6.21, 1.6.25, 1.6.28, 1.6.33 and 1.6.37), the problem goes away, although the flag is still here:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -I/usr/local/include -I. -I../ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -MD -MT CMakeFiles/png16_static.dir/pngrio.o -MF CMakeFiles/png16_static.dir/pngrio.o.d -o CMakeFiles/png16_static.dir/pngrio.o -c ../pngrio.c
This means that I could update my submodule use one of these releases and my problem would go away.
However, if I'm not not mistaken, -I flags are resolved from left to right: I therefore suspect that my Homebrew headers are used instead of the source ones. If I'm right, then this doesn't guarantee that a Homebrew upgrade of libpng won't break the build again: it just shows that libpng's API has been stable since v1.6.21 and that I can use my Homebrew headers with the source I'm trying to compile. Am I right, or am I missing something?
answer to question: the system include path is added by compiler/preprocessor (this page will explain more datails)
the order of included in CMake project may be changed (not sure how much), CMake allows prepend includes in the list; try compare CMake build scripts between releases. I believe there will be mentioned change.
Yes sometimes cmake will pick up a variety of libs and include dirs and freely mix and match. If you need to keep multiple versions up, you should use the cmake command to pass the correct packages.
I finally got to the bottom of it. It turned out that libpng's zlib dependency was the one giving me trouble (indirectly).
What happened
MacOS ships zlib and it is usually known to developers who therefore don't feel the need to install a 3rd party zlib. However, CMake's find_package doesn't know about this preference and will pick up a zlib implementation found in /usr/local, for instance if it is installed by Homewbrew. For some reason, a zlib was installed by 3rd party software at this location on my system—not a Homebrew package, which made the detection more difficult, and it was detected by find_package.
The corresponding include directory is /usr/local/include. libpng's CMake code is such that this directory is then added to the list of include directories, which leads to the header conflicts mentioned in the question. I understood what was happening by going through CMakeCache.txt (searching for /usr/local/include), so the main lesson is: don't forget to check your CMake cache in such situations.
How to solve the problem
The lazy way. Remove the undesired lib files. I ran brew doctor and removed the files which were not supposed to be here. This, however, might have undesired consequences if the specific zlib version sitting in /usr/local is actually required by some piece of software.
The dirty CMake way. Modify the top-level CMake code to hint find_package about where it should pick zlib. Either hard-code the hint using the PATHS argument or set it using the ZLIB_ROOT argument (you might have to define policies for that).
I'm sure there is a better way to handle this by "doing CMake right" in libpng and forcing library search in system paths, but my CMake skills are not good enough to say what should be done exactly. And anyway, it's a bit off-topic with respect to the question.
I'm currently trying to compile redland (librdf http://librdf.org/) under Windows. According to their website it should build under Windows. As i don't want to spend my time fixing the .sln I thought about compiling librdf (and the necessary projects) in cygwin and then use the library in visual studio.
So my question is:
Is it possible to use librarys compile in cygwin in windows application? And if so how?
As I am a windows developer I don't know if there is any difference from the created .a files to .dlls. I already read up to the topic and it will be necessary to include the cygwin1.dll in the project but this won't be a problem.
Or does anyone have any better idea how I can get redland compiled as windows dlls?
I thought about using mingw but until now I didn't manage to compile it.
Any help will be appreciated.
Thanks
Update:
Thanks to the help of Yaakov (And his pretty cool cygwin ports) I meanwhile managed to compile raptor (which is a prerequisite for librdf).
All I had to do was include another argument for configure: --with-xml2-config=/usr/x86_64-w64-mingw32/sys-root/mingw/bin/xml2-config
Now I'm trying to compile rasqal which is another requesite and is also depending on raptor2.
For it to work I had to export PKG_CONFIG_PATH="/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/" for pkg-config to find the correct raptor installation.
So configure for rasqal worked but when I try to make it I get the following error:
Making all in src
make[1]: Entering directory `/home/Stefan/workspace/rasqal/src'
make all-am
make[2]: Entering directory `/home/Stefan/workspace/rasqal/src'
/bin/sh ../libtool --tag=CC --mode=compile x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -DRASQAL_INTERNAL=1 -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/raptor2 -g -O2 -DMTWIST_CONFIG -I../libmtwist -g -O2 -MT rasqal_algebra.lo -MD -MP -MF .deps/rasqal_algebra.Tpo -c -o rasqal_algebra.lo rasqal_algebra.c
libtool: compile: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -DRASQAL_INTERNAL=1 -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/raptor2 -g -O2 -DMTWIST_CONFIG -I../libmtwist -g -O2 -MT rasqal_algebra.lo -MD -MP -MF .deps/rasqal_algebra.Tpo -c rasqal_algebra.c -DDLL_EXPORT -DPIC -o .libs/rasqal_algebra.o
In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/sys/time.h:10:0,
from rasqal.h:116,
from rasqal_algebra.c:39:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/time.h:260:8: error: redefinition of 'struct timezone'
./win32_rasqal_config.h:62:8: note: originally defined here
Makefile:1045: recipe for target `rasqal_algebra.lo' failed
make[2]: *** [rasqal_algebra.lo] Error 1
make[2]: Leaving directory `/home/Stefan/workspace/rasqal/src'
Makefile:720: recipe for target `all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/Stefan/workspace/rasqal/src'
Makefile:484: recipe for target `all-recursive' failed
make: *** [all-recursive] Error 1
Which I can't get my head around I'm not really into cross compiling.
Can someone point me into the right direction?
The MSVC and Cygwin runtimes are incompatible, so you cannot use a Cygwin-compiled binary within VS. However, you can use Cygwin to cross-compile a library for Windows, which for C libraries, should be compatible with VS. (C++ is very compiler-specific, particularly with symbol mangling, but IIRC these libraries are all in C.)
To get started, you need to install the mingw64-i686-gcc-core, mingw64-i686-headers, and mingw64-i686-runtime packages, plus all dependencies, via Cygwin's setup.exe installer. Then, beginning with the "bottom" of the dependency chain, build each library with e.g.:
./configure --prefix=/usr/i686-w64-mingw32/sys-root/mingw --host=i686-w64-mingw32
Then run make followed by make install. For Windows x64, substitute all the i686s above with x86_64.
Keep in mind that librdf has a lot of (sub)dependencies, but I don't remember now how many are optional. Some, but not all, of these are available from the Cygwin Ports repository; those should at least help you get started.
I recommend you to build raptor2 using Visual Studio.
I did this successfully for Visual Studio 2017 x64 this way:
Install libxml2 and libxslt
Open PowerShell:
git clone https://github.com/Microsoft/vcpkg
cd vcpkg
.\bootstrap-vcpkg.bat
.\vcpkg install libxml2:x64-windows
.\vcpkg install libxslt:x64-windows
Build raptor2
Download raptor: http://librdf.org/raptor/ (http://download.librdf.org/source/raptor2-2.0.15.tar.gz)
Change raptor2-2.015/CMakeLists.txt, line 258:
ADD_DEFINITIONS(-DHAVE_CONFIG_H)
->
ADD_DEFINITIONS(-DHAVE_CONFIG_H -DYY_NO_UNISTD_H)
change raptor2-2.015/src/CMakeLists.txt, line 118:
ADD_LIBRARY(raptor2
raptor_avltree.c
...
->
ADD_LIBRARY(raptor2
raptor_escaped.c
sort_r.c
raptor_ntriples.c
raptor_avltree.c
...
open cmake:
set LIBXML2_INCLUDE_DIR to: path/to/vcpkg/installed/x64-windows/include
set LIBXML2_LIBRARIES to: path/to/vcpkg/installed/x64-windows/lib/libxml2.lib
set LIBXSLT_INCLUDE_DIR to: path/to/vcpkg/installed/x64-windows/include
set LIBXSLT_LIBRARIES to: path/to/vcpkg/installed/x64-windows/lib/libxlst.lib
set LIBXSLT_EXSLT_LIBRARY to: path/to/vcpkg/installed/x64-windows/lib/libexlst.lib
Deployment:
Set CMAKE_INSTALL_PREFIX to your deplyoment path e.g. C:\thirdparty\vs2017\x64\raptor2
Execute the INSTALL target in Visual Studio.
If you do not like to execute this steps manually you can just download a prebuild version here.
I just did
1.download omnetpp-5.5.1-src-windows.zip
2.unzip it
3.run mingwenv.cmd
4.configure&make
5.run omnetpp
6.Check the "Install INET ..." Checkbox (It checked by default)
7.Go to inet/tutorials/wireless/omnetpp.ini ,Click run
Failed.
Summarize, I didn't change anything, I just download and run the tutorials of inet.
OMNeT++ Discrete Event Simulation (C) 1992-2019 Andras Varga, OpenSim Ltd. Version: 5.5.1, build: 190613-08ba16f914, edition: Academic Public License -- NOT FOR COMMERCIAL USE See the license for distribution terms and warranty disclaimer
<!> Error: Cannot load library '../../src//libINET.dll': 找不到指定的程序?
End.
Simulation terminated with exit code: 1 Working directory: E:/omnetpp-5.5.1/samples/inet/tutorials/wireless Command line: ../../../../bin/opp_run.exe -m -n ../../src;../../examples;..;../../showcases --image-path=../../images
-l ../../src/INET omnetpp.ini
Environment variables: PATH=;E:/omnetpp-5.5.1/samples/inet/src;E:\omnetpp-5.5.1\bin;E:\omnetpp-5.5.1\tools\win64\mingw64\bin;E:\omnetpp-5.5.1\tools\win64\usr\bin;;E:/omnetpp-5.5.1/ide/jre/bin/server;E:/omnetpp-5.5.1/ide/jre/bin;E:/omnetpp-5.5.1/ide/jre/lib/amd64;.;E:\omnetpp-5.5.1\bin;E:\omnetpp-5.5.1\tools\win64\mingw64\bin;E:\omnetpp-5.5.1\tools\win64\usr\local\bin;E:\omnetpp-5.5.1\tools\win64\usr\bin;E:\omnetpp-5.5.1\tools\win64\usr\bin;C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;E:\omnetpp-5.5.1\tools\win64\usr\bin\site_perl;E:\omnetpp-5.5.1\tools\win64\usr\bin\vendor_perl;E:\omnetpp-5.5.1\tools\win64\usr\bin\core_perl;E:\omnetpp-5.5.1; OMNETPP_ROOT=E:/omnetpp-5.5.1/ OMNETPP_IMAGE_PATH=E:\omnetpp-5.5.1\images
Run failed screenshot
I ran it in the commandline it's the same error message too.
Run in command line
Actually it is not the winpcap problem, because I googled about that all the answer said to install winpcap but I tried it doesn't works. And those situation are unable to build inet.
BUT!!!! On my situation, omnetpp and inet all are build SUCCEED! SO actually I had this file(libINET.dll). So this point it is sooo strange.
21:04:19 **** Incremental Build of configuration release for project inet ****
make MODE=release -j4 all
cd src && /usr/bin/make
make[1]: Entering directory '/e/omnetpp-5.5.1/samples/inet/src'
*** COMPILING with:
clang++ -c -std=c++11 -O3 -DNDEBUG=1 -MMD -MP -MF .d -isystem /usr/include -isystem /mingw64/include -Wno-deprecated-register -Wno-unused-function -fno-stack-protector -DXMLPARSER=libxml -DPREFER_QTENV -DWITH_QTENV -DWITH_PARSIM -DWITH_NETBUILDER -DWITH_OSG -DWITH_OSGEARTH -DINET_EXPORT -Wno-overloaded-virtual -include inet/common/precompiled_release.h -DINET_EXPORT -I. -IE:/omnetpp-5.5.1/include
*** LINKING with:
clang++ -shared -o ../out/clang-release/src/libINET.dll -Wl,--no-as-needed -Wl,--whole-archive -lws2_32 -Wl,--no-whole-archive -loppenvir -loppsim -lstdc++ -losg -losgText -losgDB -losgGA -losgViewer -losgUtil -lOpenThreads -losgEarth -losgEarthUtil -Wl,-rpath,E:/omnetpp-5.5.1/lib -Wl,-rpath,E:/omnetpp-5.5.1/tools/win64/lib -Wl,-rpath,. -L/usr/bin -L/usr/lib -L/mingw64/lib -LE:/omnetpp-5.5.1/lib
Building...
make[1]: Nothing to be done for 'all-pch'.
make[1]: Leaving directory '/e/omnetpp-5.5.1/samples/inet/src'
21:04:22 Build Finished. 0 errors, 0 warnings. (took 3s.519ms)
libINET.dll in Windows Explorer
libINET.dll is existed
But I can run tictok. So I think omnet++ is works and only Inet doesn't works.
tictok is works fine
I checked my %PATH% it is normal.
echo %PATH%
I am using Windows 7 64bit. In fect I did the same step in a fresh installed same version of win7 or win10 on a virtual machine everything work fine.
Of cause I tried rebuild remake everything even redownload the omnet++ package.
And I also checked everything about my operating system seems no problem and other softwares in my OS all are work fine.
So what can I do and what should I do now?
Thanks!
Process Monitor Screenshot
Finally I solved this problem by using Process Monitor to analyse what dll it loaded. Left side is not working and right side is woking fine in a virtual machine.
I found the difference is the final DLL it loaded is libeay32.dll, from SYSTEM32, and then crashed. And in the working VM it loads from omnet++ own folder, and continue loads others dll.
So I found a wrong version of libeay32.dll in system32 and it is installed by other software. This is a OpenSSL dll and a software use OpenSSL and it put the old version of OpenSSL in SYSTEM32 while it installed.
So I just delete the libeay32.dll from SYSTEM32 and everything works fine now.