Download source files from official OpenSSL site. I follow the INSTALL.M32 file in OpenSSL folder. I open msys.bat, go to the OpenSSL folder, then type
$ ./config
It says "Configured for MinGW", than I type
$ make
and after few minutes receive error:
md2test.c:1:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before '.' token
I simply opened the files that were causing the error (/test/"md5test.c; rc5test.c; jpaketest.c") and replaced the line
dummytest.c
to
#include "dummytest.c"
It's the same solution as stated above, except it's a bit faster...
The problem is that md2test.c is actually a symbolic link, or symlink to dummytest.c.
If you extracted openssl-1.0.1c.tar.gz with anything other than
tar xf openssl-1.0.1c.tar.gz
then these symlinks were not preserved. On Cygwin it works after that; not sure about MinGW.
In my case the problem was that few test files (3 as far as I remember) had instead of C++-code the name of file (something like dummitest.c). I copy-paste the right code to that files from files from other folder, but with the same name, and everything went fine.
What program did you use to decompress 'openssl-1.0.0x.tar.gz'? 7-zip is a great program, but it seems there's a bug.
Use tar or other decompressor such as BreadZip.
tar zvxf openssl-1.0.0x.tar.gz
It's the same solution as stated above, except it's a bit faster... :)
The problem is a symbolic link in the archive that MinGW/MSYS does not seem to understand.
You can work around it by using the --derefence (-h) option when extracting.
For example tar -xzvfh archive.tar.gz
from http://www.gnu.org/software/tar/manual/html_node/dereference.html:
When reading from an archive, the --dereference' (-h') option causes tar to follow an already-existing symbolic link when tar writes or reads a file named in the archive.
I am having the same problem.
As the problem is while building the tests, I just did not make them:
make Makefile openssl.pc libssl.pc libcrypto.pc build_libs build_apps build_tools
Is a horrible solution but it seems to work. You get the libraries and the tools, but not the test suite.
I hope someone gives a better answer and/or fixes the problem with the code if there is any.
Related
I have a rule whose output files are symbolic link files. Even though the link files are being made, Snakemake exits with a MissingOutputException and lists the output files as being missing. If instead of making a symlink with "ln -s" I copy the files with "cp -p" it works. I tried increasing the --latency-wait but it made no difference.
Sounds like you are using relative path for source file when symlinking. Use absolute path.
Snakemake sees broken symlinks as missing output.
I'm absolutely new to bash. I downloaded win-bash (http://win-bash.sourceforge.net/), and I ran the file titled 'start_shell'. Then, I tried some basic commands.
ls seemed to work perfectly fine, however, I'm confused as to why cd.. didn't work? It says C:\Users\USER\shell.w32-ix86/bash.exe: cd..: command not found. I stuck the zip file in my C:\users\myname folder. It seemed to make sense there.
I looked everywhere for an API or documentation of some sorts to get me started, but I couldn't find anything. Suggestions?
In Unix shells like bash, cd follows the syntax of other commands and must be separated from its argument by a space: cd ...
I recently updated to the most recent version of Cygwin (1.7.23), and what used to be a functional 'arm-elf-gcc' compiler seems to now be broken. In particular, no matter what input I supply the command, it complains that there are no input files:
$ arm-elf-gcc foo.c
arm-elf-gcc: no input files
$ arm-elf-gcc --help
arm-elf-gcc: no input files
$ arm-elf-gcc -v
arm-elf-gcc: no input files
Any ideas or suggestions as to why this could be happening? A Google search for 'arm-elf-gcc no input files' reveals little as to the cause. Thanks!
As TurboJ mentioned in the comments to the original question, there were two conflicting versions of the cygwin1.dll. The folder that contained the arm-elf-gcc executable also contained a cygwin1.dll, which clashed with the one from the 'bin' subdirectory of Cygwin. I merely replaced the former with the latter.
As Jon Kother says, If you Installed Gnu arm and checked install cygwin.dll and cygwin 32 version,this problem will happen
so just go to your X:/gunarm/bin/ and rename cygwin.dll to cynwin.dll.bak,And everything will to alright
I can't figure out what the issue is here. I am in a directory:
pwd
/afs/naf.desy.de/user/e/eron/scratch/UserCode/devRA4b/UserCode/DesySusy/ra4b_2012
where I have an executable called myAnalysis. However, I also have another directory called
/afs/naf.desy.de/user/e/eron/scratch/UserCode/RA4bHead/UserCode/DesySusy/ra4b_2012/
I am now in the first one, and if I do:
gdb myAnalysis
I get:
`
Reading symbols from `/afs/naf.desy.de/user/e/eron/scratch/UserCode/RA4bHead/UserCode/DesySusy/ra4b_2012/myAnalysis...done.
why does it take the executable from the wrong directory and how can I solve that?
Thanks a lot!
Try:
gdb ./myAnalysis
Also make sure that your other folder isn't in your path. I thought that '.' was implicitly at the head of the search path, but apparently not for all OSes.
I downloaded a "directory".tar.gz, extracted and unzipped the file to obtain "directory".
The installation files for this directory, were to run the make command in cygwin, to compile and pull out the files of the directory, which were written in C.
I attempt to run a command in cygwin, pfunc, which is a command supposed to be available after compiling and performing make, but cygwin says command not found.
I'm completely new to unix and cygwin.
The problem is that pfunc, if it exists, is not on your path.
The first step is to see if pfunc actually exists and if so, find out where. find / -xdev -name pfunc will give you the location of all files named pfunc. Obviously, if pfunc doesn't exist, you have another problem on your hands.
Next, you'll want to add this path to your bashrc. You can do that with:
echo "export PATH=$PATH:<the/path/find/gave/you> >> ~/.bashrc
Finally, you need to update your path in the current shell with source ~/.bashrc
K, I figured it out, there was a problem with the implementation of the program on cygwin, and for some reason find -name ....etc couldn't find the file. However, I found the location and reset the path to find the .exe file. Now everything looks good! thanks again!