I kind of am struggling with OpenSSL over here. I downloaded the current release 1.0.1 and the compilation itself works. I can even call ./apps/openssl.exe. But when I get to the linking process the linker complains:
/usr/i686-pc-mingw32/sys-root/mingw/lib/libmingw32.a(main.o): In function `main':
/usr/src/mingw-runtime/mingw-runtime-3.20-1/src/mingwrt-3.20-mingw32/main.c:73: undefined reference to `_WinMain#16'
(this is if I use mingw in cygwin, the same error occurs with cygwin itself)
This is the cygwin error:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xba): undefined reference to `_WinMain#16'
Now I found out that this means that it doesn't find a main function, but this couldn't actually be, can it? I mean openssl HAS its main-function. And concerning mingw: I can't find that file it mentions so there could be cause of the error, but libcygwin.a does exist (though I have no idea how to figure out if it has a main function).
So basically I ask: Why does this error occur that only occurs if I don't add a main function. Did I miss something?
Edit: Sorry to have missed that: I am on Win 7 x64 Enterprise
See this for a solution. Steps summarized below:
unpack the .tar with the msys tools and NOT 7-zip.
Use tar -xzf openssl-x.y.z.tar where x.y.z denotes your version.
Then run the commands and it will work like a charm.
Related
i am new to stackflow and i previously i have no background in computer system and programming. However, now i need to run analysis under cygwin for my bioinformatics project. I encounter some error when i try to compile a file name 'zone_b.linux'using cygwin, to produce an executable program. The linux file is download from web https://github.com/haddocking/HADDOCK-binding-sites-tutorial/blob/master/ana_scripts/zone_b.linux. When i try to compile using the following command under cygwin it produce the following error:
$ gcc zone_b.linux
/usr/lib/gcc/i686-pc-cygwin/6.4.0/../../../libcygwin.a(libcmain.o): In
function `main':
/usr/src/debug/cygwin-2.9.0-3/winsup/cygwin/lib/libcmain.c:37: undefined
reference to `WinMain#16'
collect2: error: ld returned 1 exit status
Error description
I search the following error under stackoverflow, and i found two post with similar problem.
First is the post from undefined reference to `WinMain#16'. It stated that the problem is due the Microsoft'linker uses a runtime library entry point(winMainCRTStartup) that calls Microsoft's non-standard WinMain instead of standard main. So, i try the post's suggestion of including the entry by following command
$ gcc zone_b.linux /entry:winMainCRTStartup
gcc: error: /entry:winMainCRTStartup: No such file or directory
However i get the error no such file or directory. I think maybe it is because i am running under cygwin not mingW.
Second post is the Undefined reference to WinMain in Cygwin. From the post, it said use -c compile flag to only produce object file. However, for my case, i am not using any -c. Therefore, i think it is not relevant to my issue.
I would appreciate if anyone could kindly explain to me since i am new to this computing area. Thank you.
zone_b.linux is the compiled and linked executable program to run on a linux machine. It is a 32-bit ELF binary file. It will not work on a Windows machine, even using cygwin or mingw32, without re-compulation.
You probably have to compile zone_b.f, a FORTRAN source file, using the gfortran compiler to create a zone_b.exe that is usable in cygwin. I saw no instructions for this, but try something like gcc zone_b.f and cross fingers. Be sure gfortran is installed using cygwin setup.
You will also need to (re-)build the other executables (cluster_struc and contact) by performing make in the ana_scripts directory. Any supplied executables (from the git clone ... or a downloaded .zip file) will not work under cygwin.
You will need to have perl and python installed. I think perl is installed by default. You can install python2 using cygwin setup. The python script looked like it will work with python2 or python3, whichever is the default. On cygwin, today, python2 is the default python. I don't do perl, so cross your fingers.
I am trying to cabal install a component of wxHaskell (Haskell platform 2013.2 against wxWidgets 3.0).
I was able to compile the git version with 32 bit mingw from mingw.org. But in the end, the installed wx cannot function correct, and running a minimal example gives runtime exceptions in wxc.dll. So I try to compile the same thing under TDM-GCC 4.8.1 64bit, since the wxWidgets people provide their binary in the form of TDM-GCC compiled binaries.
But I immediately run into compilation errors with TDM-GCC, telling me
error: 'strnlen' was not declared in this scope
What surprises me is that even though both mingw32 and TDM-gcc uses the same external gcc from Haskell Platform c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe, one would give an error while the other compiles fine.
The first file causing problem is src\cpp\eljaccelerator.cpp. It compiles OK under mingw32:
...
c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe -Wl,--hash-size=31 -Wl,--reduce-
memory-overheads -Isrc/include -IC:/MinGW/msys/1.0/local/include/wx-3.0 -IC:/Min
GW/msys/1.0/local/lib/wx/include/msw-unicode-3.0 -D__WXMSW__ -DWXUSINGDLL -D_LAR
GEFILE_SOURCE=unknown -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\eljaccelerato
r.cpp -o dist\build\src/cpp/eljaccelerator.o
but gives an error under TDM-gcc:
Building wxc
c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe -Wl,--hash-size=31 -Wl,--reduce-
memory-overheads -Isrc/include -IC:/mingw/msys/1.0/local/include/wx-3.0 -IC:/min
gw/msys/1.0/local/lib/wx/include/msw-unicode-3.0 -D__WXMSW__ -DWXUSINGDLL -D_FIL
E_OFFSET_BITS=64 -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\eljaccelerator.cpp
-o dist\build\src/cpp/eljaccelerator.o
In file included from C:/mingw/msys/1.0/local/include/wx-3.0/wx/crt.h:19:0,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/string.h:4305,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/memory.h:15,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/object.h:19,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/wx.h:15,
from src/include/wrapper.h:20,
from src\cpp\eljaccelerator.cpp:1:
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const char*, size_t)':
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:173:92: error: 'strnlen' was n
ot declared in this scope
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const wchar_t*, size_t)':
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:187:95: error: 'wcsnlen' was n
ot declared in this scope
Failed to install wxc-0.90.1.1
I was wondering if anyone has any similar experience. Any idea what went wrong and how to fix compilation for TDM-GCC? I tried adding #include <cstring> to wxcrt.h but it doesn't change anything.
FYI, I have compiled wxWidgets 3.0.0 from source in mingw and tdm-gcc versions respectively, using
./configure --enable-stl && make && make install
I can provide more details if needed.
First of all, wxWidgets certainly does work with MinGW, the fact that only TDM binaries are provided simply means that someone volunteered to provide the latter but not the former. But all three popular versions of MinGW (the two already mentioned and MinGW-w64) do work, so there must be something wrong with the build...
However while they all work, they are certainly different compilers, so what do you mean that they both use the same gcc binary? It must be either a MinGW one or a TDM one, but it can't be both at once.
It's also very suspicious that the configure detects different flags to use for the large file support. Look at config.log, something must have gone wrong and there must be some errors in the initial stage in it.
I'm attempting to compile a relatively simple Fortran executable so that it can be passed around to other Windows users that don't have Cygwin (or something of the sort) installed, however, I'm unable to get the executable to operate as a standalone. I've tried gfortran -static file.f and gfortran -static-libgfortran file.f, however other users always encounter this error:
The program can’t start because cygwin1.dll is missing from your computer. Try reinstalling the program to fix this problem.
From what I've read online (e.g. here), the -static option should be sufficient. I have verified that running the executable from my machine (DOS prompt) does work.
I have gcc (gfortran) version 4.7.3. I should also point out this is my first attempt at compiling portable Fortran.
Update
After realizing that this isn't a gfortran-specific issue (thanks to replies here), searches led me to related posts here and here
This is partially explained in the Cygwin FAQ. The solution is to install the mingw64-i686-gcc-fortran package with its dependencies, and cross-compile your code with i686-w64-mingw32-gfortran -static.
Just package the cygwin1.dll along with your binary file (both in the same folder) then it will run just fine.
I'm in the process of attempting to port some code across from PC to Ubuntu, and am having some issues due to limited experience developing under linux.
We use CMake to generate all our build stuff. Under windows I'm making VS2010 projects, and under Linux I'm making Eclipse projects. I've managed to get my OpenCV stuff ported across successfully, but am having major headaches trying to port my threaded boost apps.
Just so we're clear, the steps I have followed so-far on a clean Ubuntu 12 installation. (I've done 2 clean re-installs to try and fix potential library cock-ups, now I'm just giving up and asking):
Install Eclipse and Eclipse CDT using my package manager
Install CMake and CMake Gui using my package manager
Install libboost-all-dev using my package manager
So-far that's all I've done. I can create the eclipse project using CMake with no errors, so CMake is successfully finding my boost install. When I try and build through eclipse is when I get issues; The app I'm attempting to build uses boost::asio for some UDP I/O and boost::thread to create worker threads for the asio I/O services. I can successfully compile each module, but when I come to link I get spammed with errors such as:
/usr/bin/c++ CMakeFiles/RE05DevelopmentDemo.dir/main.cpp.o CMakeFiles/RE05DevelopmentDemo.dir/RE05FusionListener/RE05FusionListener.cpp.o CMakeFiles/RE05DevelopmentDemo.dir/NewEye/NewEye.cpp.o -o RE05DevelopmentDemo -rdynamic -Wl,-Bstatic -lboost_system-mt -lboost_date_time-mt -lboost_regex-mt -lboost_thread-mt -Wl,-Bdynamic
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libboost_thread-mt.a(thread.o): In function `void boost::call_once<void (*)()>(boost::once_flag&, void (*)()) [clone .constprop.98]':
make[2]: Leaving directory `/home/david/Code/Build/Support/RE05DevDemo'
(.text+0xc8): undefined reference to `pthread_key_create'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libboost_thread-mt.a(thread.o): In function `boost::this_thread::interruption_enabled()':
(.text+0x540): undefined reference to `pthread_getspecific'
make[1]: Leaving directory `/home/david/Code/Build/Support/RE05DevDemo'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libboost_thread-mt.a(thread.o): In function `boost::this_thread::disable_interruption::disable_interruption()':
(.text+0x570): undefined reference to `pthread_getspecific'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libboost_thread-mt.a(thread.o): In function `boost::this_thread::disable_interruption::disable_interruption()':
(.text+0x59f): undefined reference to `pthread_getspecific'
Some Gotchas that I have collected from other StackOverflow posts and have already checked:
The boost libs are all present at /usr/lib
I am not getting any compile errors for inability to find the boost headers, so they must be getting found.
I am trying to link statically, but I believe eclipse should be passing the correct arguments to make that happen since my CMakeLists.txt includes SET(Boost_USE_STATIC_LIBS ON)
I'm officially out of ideas here, I have tried doing local builds of boost and a bunch of other stuff with no more success. I even re-installed Ubuntu to ensure I haven't completely fracked the libs directories and links with multiple weird versions or anything else. Any help would be muchly appreciated.
Correct mechanism is to use Threads package:
find_package(Threads)
#...
target_link_libraries(my_app ${CMAKE_THREAD_LIBS_INIT} ...)
See also cmake and libpthread
When you are building your targets, add -lpthread and it will compile.
See this other thread.
OK, so I found the solution.
It was to do with the absence of the -lpthread flag in the link command. In order to get CMake to link appropriately, then the TARGET_LINK_LIBRARIES line needs to be edited. My edit is:
Original:
TARGET_LINK_LIBRARIES( RE05DevelopmentDemo ${Boost_LIBRARIES} )
Modified and working:
IF(WIN32)
TARGET_LINK_LIBRARIES( RE05DevelopmentDemo ${Boost_LIBRARIES} )
ELSE(WIN32)
TARGET_LINK_LIBRARIES( RE05DevelopmentDemo ${Boost_LIBRARIES} pthread )
ENDIF(WIN32)
I'm guessing that I should probably change the ELSE(WIN32) to an elseif for or use the CMake command FindThreads to link in pthread if needed, but I'm not sure how to do that at the moment and have more imporatant things on my plate given the time I've lost. Interestingly enough, I noticed my link command now has two -lpthread flags appended at the end, one after another, but everything is still compiling quite happily.
I am moving a project which uses clapack from osx to linux and experiencing some problems with it. I use clapack by downloading the cmake project, compiling and moving the necessary .h and .a files to a relevant location within my project.
I have used the same steps in both scenarios (osx and linux) and have the same exact source code on both machines however I cannot get the everything to link properly on linux.
the lined of code in my cmake file look like this
#-----------------------------------------------------------------------------
# INCLUDE CLAPACK
#-----------------------------------------------------------------------------
INCLUDE_DIRECTORIES(${VMT_PRJ_SOURCE_DIR}/CLAPACK)
LINK_DIRECTORIES(${VMT_PRJ_SOURCE_DIR}/CLAPACK/lib)
LINK_LIBRARIES(blas f2c lapack tmglib)
and the error I am getting looks like this
/CLAPACK/lib/liblapack.a(sgesvd.c.o): In function `sgesvd_':
sgesvd.c:(.text+0x456): undefined reference to `s_cat'
sgesvd.c:(.text+0x1fa4): undefined reference to `s_cat'
This is the first time I have done a port from osx to linux and don't know if there are some different requirements I need to make in order to link or what the problem is
Any help would be much appreciated.
Scott
The order of linking matters. Since liblapack.a needs functions from libf2c.a, the latter needs to come after the former. So changing
LINK_LIBRARIES(blas f2c lapack tmglib)
to
LINK_LIBRARIES(blas lapack f2c tmglib)
should help.