I am trying to use RCurl (from within the R programming language). And I get the following error:
The procedure entry point
ASN1_const_check_infinite_end could
not be located in the dynamic link
library libeay32.dll
Before that I had the warning that libeay32.dll is missing. I downloaded some copy from online, and put it into the system32 directory - and I ended up with the error above.
I then ran regclean pro (link) but that didn't help either.
I work on win 7. Any suggestions how to solve this?
(I wasn't sure if this belongs here on superuser, so I tried both)
That error is caused by using an older DLL that the one needed by RCurl. It means that the Windows library loader couldn't locate in the library a function that RCurl wants to use.
You need a newer version, try downloading it from the OpenSSL official page, current version is 0.9.8.8:
http://gnuwin32.sourceforge.net/packages/openssl.htm
http://downloads.sourceforge.net/gnuwin32/openssl-0.9.8h-1-bin.zip
Note also that you don't need to put int in system32, it's better is you put it in the RCurl directory (MS no longer recommends putting libraries in system folders because of DLL Hell).
I had the same error. I found updating the RCurl package:
update.packages("RCurl")
solved the problem.
Related
I have compiled Lua 5.3 as a 32 bit c++ DLL and exe. The DLL contains all the lua code except for lua.cpp and luac.cpp. The exe compiles lua.cpp and uses the DLL to run the lua interpreter. This works fine when running on its own from the command line. I wish to be able to run from the IDE using this DLL and exe.
If I replace /ZeroBraneStudio/bin/lua53.dll and lua53.exe with my own versions, I can run scripts (clicking the two green arrows). However, debugging does not work, giving the following error:
The procedure entry point luaL_addlstring could not be located in the dynamic link library lua53.dll.
I can see that this is happening because the debugger is making use of luasocket. \ZeroBraneStudio\bin\clibs53\socket\core.dll is dependent on lua53.dll, and is expecting it to contain lua compiled as c.
So, what is the correct solution to this - is it to compile luasocket as c++ as well?
(And, if so, does anybody have instructions/guidance for doing so? I have been unable to find anything on this.)
Thanks.
I'm not sure how exactly the DLL was compiled, but the error message likely indicates that the luaL_addlstring and other functions are not exported by it. If the symbols are exported correctly, you should be able to load luasocket and get the debugging working. See this thread for the related discussion.
Also, you don't need to replace lua53 library and executable, as you can configure the IDE to use your own copy of it using path.lua53 configuration setting as described in the documentation.
Okay, I was able to get it working. The solution was to compile luasocket as c++. I won't give full instructions on how to do this here, but some points to hopefully help anybody else with the same issue:
Got luasocket from here: https://github.com/diegonehab/luasocket
Renamed all *.c files to *.cpp
Renamed Lua52.props to Lua.props (I am using lua 5.3 but seems like it is compatible?)
Placed lua headers and lib in appropriate folders
Opened solution in Visual Studio 2012
Fixed up minor issues with project files, like the renaming of the files.
Added 'extern "C"' to declaration of luaopen_socket_core and luaopen_mime_core functions (necessary for lua to be able to load libraries).
Built solution
Copied new dlls into clibs53/socket and clibs53/mime folders.
I used Dependency Walker to help with this. If anybody wants further details in the future please leave a comment.
I have CMake working perfectly fine with Visual Studio 2015. I wanted to try VS Code with C++ and CMake extensions, but when I try to call the build command (configured to F7 by default with the CMake extension for VSCode), I only get the message:
command 'cmake.build' not found
Is it trying to tell me it can't find CMake ? Because Cmake is installed and working so... I also tried changing in the settings to the full path to cmake with no success. I installed both CMake and CMake Tools from Extensions. Also the toolbar for CMake doesn't appear on the blue VSCode toolbar as shown in CMake Tools extension doc.
Edit:
The author of that extension believes they've resolved this issue in the latest version 0.9.7.
https://github.com/vector-of-bool/vscode-cmake-tools/issues/157#issuecomment-307005140
So, I've just pushed 0.9.7:
No more dependency on twxs.cmake, so that shouldn't be causing any
issues anymore
#ytimenkov fixed some version parsing code that was
lying about what version of CMake was installed. Should fix issues
people are seeing with pre-3.7 versions.
#ytimenkov added better
errors when initialization failed. This should help create future
tickets!
As such, I'm going to close this issue and ask that anyone
with any further issues open a new ticket using the new error messages
that appear during a failed initialization.
I too had this issue and was given a solution here in my ticket.
For some people, one of their dependencies isn't getting installed correctly on our system. So you need to install another additional extension to get it to work.
It's called "CMake" or "twxs.cmake" (actual package name) and can be found here: https://marketplace.visualstudio.com/items?itemName=twxs.cmake
If it still isn't working, some have reported that they needed to uninstall both extensions then reinstall them both to get it to work--making sure to restart VSCode.
try this:
create a new copy of "mingw32-make.exe".
rename the copy to "make.exe".
restart your vscode.
I was using my command line on my Windows 8 pc, after I typed the ls command, then I got the following error:
ls.exe-System Error
The program can't start because cygintl-2.dll is missing from your computer. Try reinstalling the program to fix this problem.
Actually, I have googled it and watched some vids, I have tried download a cygintl-2.dll zip file, then extracted the dll file then copy it to the system32 folder. However, it still display the error. I also tried to reinstall the Microsoft Visual C++ Redistributable. it was failed also. I have no idea where I can find any help about this. Hope anyone can help me. Many Thanks!!!
It is because of the lack of cygintl-2.dll&cygintl-1.dll in OpenSSH/bin.
try finding and downloading the two dlls then copy them into OpenSSH/bin (usually it is installed in /program files/openssh/bin, or you can check the environment path to find the installation path)
I installed a newer version of OpenSSH and it fixed the problem thankfully. I was getting pretty worried! Specifically, I followed these two links (https://answers.microsoft.com/en-us/windows/forum/windows_7-performance/lsexe-system-error-how-to-browse-directories/2dddf4a5-5958-4768-acd7-ab4cf816f57e?auth=1 and https://sourceforge.net/p/sshwindows/bugs/2/) and then installed the executable from this site: http://sshwindows.webheat.co.uk/
I've now been trying to get MinGW-w64 to work on my system for several days, mainly because it has a more recent GCC version, but I either set things up wrong or there's some strange problem with MinGW-w64 itself.
I've now downloaded i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb, unpacked it to C:/Dev/mingw-ruben and added the path C:/Dev/mingw-ruben/bin to the $PATH environment variable.
What I'm trying to build is SFML 2 which comes with a CMake file. Running CMake will work just fine, the compiler gets recognized and passes all test. CMake also finds the ar.exe in the C:/Dev/mingw-ruben/binfolder. After generating the MinGW Makefile I switch to the windows command line and run mingw32-make install.
There's where the problem happens, I get the error:
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libopengl32.a: No such file or directory
Or for the network library
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libws2_32.a: No such file or directory
The error seems quite obvious and on check there really is no libopengl32.a or libws2_32.a in mingw-ruben/lib/, but the files is actually located in C:/Dev/mingw-ruben/i686-w64-mingw32/lib.
Now How can I tell ar/make/cmake to not only search in the mingw-ruben/lib directory but also in the mingw-ruben/i686-w64-mingw32/lib?
Would it be a good idea to copy all the content from the i686-w64-mingw32 subfolder to the mingw-ruben root folder?
As a side note: I can call mingw32-make install again and the procedure will continue but up on trying to link my application against SFML, I run into many unresolved symbol errors for the glXYZ functions from within SFML.
Further information: I'm on Windows 8 x64, but I think that doesn't really matter and yes I've tried MSYS but it doesn't resolve any of my issues.
Am I doing something wrong? Do I have to configure things specially?
January 2015 Edit
Now that SFML 2.2 has been released, this is no longer an issue and you have to link SFML's dependencies yourself when linking static.
January 2014 Edit
As of commit 165f2b1888 and f784fe4c07, which is included in the stable version SFML 2.1, MinGW-w64 compilers are supported.
However while discussing further with different parties it came to light, that the sfml_static_add_libraries marco a rather ugly hack was. In short it unpacked the static dependencies and included their obj files into the SFML library itself. This was most noticeable an issue, when trying to use your own version of GLEW, which failed since SFML was using its internal one already. The issue was brought to the forum and was pushed around for quite a bit, until Laurent finally gave in and went with the proper way of linking dependencies, which means you have to link them now on your own.
As of commit dbf01a775b, which is not included in the stable version of SFML 2.1, one has to link the SFML dependencies in the finally application, when linking statically against SFML.
Original
After some chat on the IRC we've figured it out.
It has nothing to do with MinGW but it's all SFML's fault. To reduce the dependencies list for SFML while linking statically the developer decided to manually extract the symbols from each library (opengl32, ws2_32, ...) which obviously isn't how one does things and violates some ODR rules. The actual error then occurs because the developer assumed that the library will be in the folder mingw/libbut with MinGW w64 it's located in a seperate directory mingw/version/lib and so ar.exe didn't find the library.
Solution
Removing the call to the sfml_static_add_libraries macro and then recompile. Afterwards you'll have to link all the dependencies for static linkages, like it should be.
I think it may be well a problem of the gcc distribution you downloaded.
A bit of light into the problem gives ruben's question here:
https://unix.stackexchange.com/questions/45277/executing-binary-file-file-not-found
that seems to me related to that (although it is about linux and not win)
I was having a similar problem (the name of the missing file was different) few months ago with gcc 4.7.0 linux->win crosscompiler. So until now I lived with the standard ubuntu mingw-w64 package and only yesterday I gave another try to i686-w64-mingw32-gcc-4.7.2-release-linux64_rubenvb.tar.xz and it works without issues in otherwise same environment where the previous version was failing with "..ar.exe: ... no such file". Sometimes I develop also in windows, then I use http://www.mingw.org/ that was for me much easier to setup in Win. It supports only 32bit target but for my project it is sufficient.
Well I've recently come out of the dark ages and upgraded my GCC from 3.4.4 to 4.5.0 with Cygwin (I use Netbeans 6.8 on Windows for future reference). I tried testing the new compiler by attempting to run a simple program through it. The run failed however, citing that NetBeans "cannot find -lstdc++".
Interesting.
I look in ...
C:\cygwin\lib\gcc\i686-pc-cygwin\4.5.0
...where libstdc++.a, libstdc++.dll.a, libstdc++.la, libsupc++.a, and libsupc++.la are supposed to be (they're in that spot in the 3.4.4 folder), and they're not there. I also notice something else: there's a 4.3.4 folder in...
C:\cygwin\lib\gcc\i686-pc-cygwin
which contains these exact files! Good. So I copy them in to the 4.5.0 folder and try to run the program again. This time i'm getting two other errors:
build/Debug/Cygwin-Windows/extract_fail_operations.o:/usr/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/stl_list.h:1435: undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base*)'
and:
build/Debug/Cygwin-Windows/extract_fail_operations.o:/usr/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/stl_list.h:1451: undefined reference to `std::_List_node_base::_M_unhook()'
At this point I figured that I was way over my head and decided to come for help before copying and pasting any more files. If anyone could tell me how to get this working, i'd be really appreciative.
(If any solutions involve the command line, please be warned that i'm not well versed in it... you may have to provide extra details that you wouldn't need to to other SO users!)
EDIT: The PATH variables are as follows:
C:\Program Files\SSH Communications Security\SSH Secure Shell;C:\Program Files\CVSNT\;C:\cygwin\bin
And yes, the Cygwin installed is the latest from the site.
You need to install version 4.5.0 of libstdc++6-devel.