An earlier attempt to compile ICU for Windows using MSVC and Cygwin worked fine. This time, however, after a successful
.../icu/source/runConfigureICU Cygwin/MSVC
make ends with the following error:
.../icu/source/stubdata/stubdata.c(20) : fatal error C1083: Cannot
open include file: 'unicode/utypes.h': No such file or directory
No problems with the non-MSVC Cygwin version. I am in a different directory, but it seems that this worked before.
Update. I must have compiled it in the icu/source directory before. I went back and did runConfigureICU in-place and did not see the error. I feel sad that I have to ruin my pristine icu folder, but perhaps there is no other way to compile Cygwin/MSVC. It might have something to do with how the Microsoft compiler handles paths.
Update2. making it in icu/source makes the other location work.
The answer to this is that runConfigureICU can only be called for Cygwin/MSVC in the icu/sources directory, otherwise, cl cannot get to the cygwin-based include path.
Related
While attempting to bootstrap Haskell on Windows without the Haskell Platform I ran into the following error
C:\git\Haskell\ghc\libraries\haskeline\dist-install\build/libHShaskeline-0.7.1.2.a: could not read symbols: Archive has no index; run ranlib to add one
Note that C:\git\Haskell\ghc is where I put the ghc git repo.
However whenever I looked at the file it appeared to be building correctly.
I have attempted completely clean rebuilds, and deleting the whole repo and regetting it, everything short of deleting anything related to this build and starting fresh.
I eventually figured out what was causing the issue, I realized it when I found the following notice on the Windows Platform notes for GHC.
However, the makefiles do use whatever ld and ar happen to be in your path.
This didn't seem right, and reading the configure script I noticed the following lines:
mingwbin="$hardtop/inplace/mingw/bin/"
LD="${mingwbin}ld.exe"
Note that mingwbin refers to the location that the tarballs are extracted to. Looking at the timestamps of the executables did not match up to the version that which ld returned (in /mingw/bin).
Given the note that meant that at some point /inplace/mingw/bin/ld.exe was being used while at another point /mingw/bin/ld.exe was being used, possibly causing the issue.
Running the following command before make resolved the issue.
export PATH=/c/git/Haskell/git/inplace/mingw/bin:$PATH
When I tried to run an installer that uses GLEW as one of its dependencies, I got:
fatal error: GL/glew.h: No such file or directory
Downloaded glew1.10 from the official site and installed according to given instructions.
After that I got the same error again- did some research and copied glew.h to /usr/include/GL/glew.h. Ran the installer again and this time got:
/usr/bin/ld: error: cannot find -lGLEW
To my understanding this is a a common error in Linux for many projects and many libraries, probably I should copy some files from the source folder or add some path to an environment variable, what should i do?
I know that there are apt-get packages- libglew1.6-dev and libglew1.6, but its built upon glew1.6, which works but is probably out-dated for what i'm trying to build.
The automatic installer is node.js's npm, and what causes this error is trying to install node-webgl module.
Solved.
As it turned out, the installation seems to have placed the needed files inside /usr/lib64, and the linker searched for those files inside /usr/lib/ which probably is the right behavior in most cases.
Since i'm not familiar with node.js's npm (and with linking in general), my fix was as follows:
sudo cp /usr/lib64/libGLEW* /usr/lib/
sudo cp /usr/lib64/pkgconfig/* /usr/lib/pkgconfig/
Meaning, I reconstructed the same hirarchy inside the /usr/lib folder. This is probably not a best practice, but it works.
I previously had some troubles updating old code that still needed a not supported compiler and expensive libraries to a version with gfortran in Eclipse on Windows. I let it rest for a while and recently I took a whole other approach, rebuilding the program from scratch, developping on a ubuntu machine, but now I want to bring it back to a windows machine so that my co-workers can contribute on it.
The status:
Program compiles, runs and gives good results on an ubuntu machine with the GCC GNU compiler
Windows 7 machine, 64bit
Cygwin installation (for gnu fortran) with lapack and liblapack-devel (however, I don't use these, because I compile blas and lapack manually)
(C:/cygwin/lib added to windows Path)
Original Issue:
The program compiles in cygwin (by calling the make-command, calling the make command with the makefile situated here: http://thijsvandenbrande.be/phd/hamfemInstall/makefile
This returns the file hamfem.exe which returns the following error when runned by double-clicking on it in windows: The program can't start because cyglapack-0.dll is missing from your computer. Try reinstalling the program to fix this problem.
When running the executable from cygwin, by calling the ./hamfem.exe command the executable starts to run. However, I want a solution so that I can give this executable to my co-workers so that they can change the input files (located in a folder in that has a relative path to the executable).
Going further on the comments below, I tried the next things:
Adding the exact path to the C:\cygwin\lib\lapack\cyglapack-0.dll file in windows path and even rebooting afterwards doesn't help.
adding a -static to the makefile before calling the library, resulting in dependency errors because I use two commands of the lapack library that depend on quite a lot of other commands (DPBTRF and DPBTRS). These commands are used in the mainprog.f90 module. The error: /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../liblapack.a(dpbtrf.f.o): In function 'dpbtrf':
/usr/src/debug/lapack-3.4.2-1/SRC/dpbtrf.f:277: undefined reference to 'dtrsm_'
and a couple of more lines stating the dependencies.
add the liblapack.a file to the src folder, but compiler always goes back to the lapack in cygwin
On the website of lapack you can normally download the functions with their dependencies (example DPBTRF), but these are not available anymore. Does anyone have another idea how to include these two functions and their dependencies in a static library-file that I can compile beforehand and add to the src-folder?
Current (semi-)Fix
The next thing worked (a bit) for me: following the instructions on http://gcc.gnu.org/wiki/GfortranBuild to manually build libblas.a and liblapack.a in the /usr/src folder of Cygwin and refering to this folder in the makefile. The updated makefile can be found here: http://thijsvandenbrande.be/phd/hamfemInstall/makefileNew
The code compiles nicely on Windows by running the make command from cygwin (next step in the process, running it out of Eclipse) and i get a .exe file that can be run by double clicking it and that keeps running if I move it with its folder to another location. Because this process is quite labour intensive, figuring it all out, I added the answer here below, stating the commands you have to parse to cygwin in order to make it work.
For your information: my file structure looks like this (after the build, I move the .exe file one folder up, both in the linux version as the windows version):
hamfem.exe
in
input.txt
NGCR_building01.txt
out
(empty folder for output files of the routine)
src
hamfem.f90 (main file)
mainprog.f90 (file that contains the commands from lapack)
...(a bunch of other modules)
makefile
I figured things out myself, with some pointers from all over stackoverflow. In order for others to help them resolve similar issues, I would like my work method here so that the question is fully documented.
The issue can be resolved by clean building the Lapack library !and the Blas library on your local machine in cygwin and pasting the liblapack.a and libblas.a file to the library folder that you refer to in the makefile. The errors that were casted by calling Lapack staticly where a result of some routines of Blas used in the two commands.
These are the steps I followed:
download the lapack.tgz and blas.tgz files from the website and past them in the C:\Cygwin\usr\src folder
Extract these files with the following commands in cygwin:
cd /usr/src
tar -xvzf lapack.tgz
tar -xvzf blas.tgz
Build the two library files with the commands shown below in Cygwin. Compiling Lapack can take a while and will result in some errors in the end because of some missing links in the test files. These tests are run for accuracy tools. A more detailed look into the make.inc file is needed to resolve these issues.
cd $HOME
cd /usr/src/BLAS
make
mv blas_LINUX.a ../libblas.a
cd ../lapack-3.4.2
mv make.inc.example make.inc
make
mv liblapack.a ../liblapack.a
check the makefile included in this repository for the correct linking to the libraries. These should say /usr/src and -static -llapack -lblas, the other options are for the linux compiler.
I am getting the following error when i build my code using regex.hpp I am using VS2010 VC++
fatal error C1083: Cannot open include file: 'boost/regex.hpp': No such file or directory
boost\boost_regex-vc71-mt-1_33_1.lib file is here.. is this correct?
It sounds like your include settings do not have the path to the boost installation parent directory.
Look at these instructions: http://www.boost.org/doc/libs/release/more/getting_started/windows.html#build-from-the-visual-studio-ide
and note especially the include directory setup.
You need to make sure that you have included the path to the Boost header files in Visual C++.
Follow the instructions here.
This issue arises because Visual C++ does not include the path to the Boost header files. By including the directory, Visual C++ will search that directory for the problem and hopefully your problem should be solved.
Maybe the error message is true? The file is not there?
If you are in Ubuntu, install the boost library with synaptic, including the regex package. It is not enough with downloading from the boost website and building the regex library in the computer (instructions in http://www.boost.org/doc/libs/release/libs/regex/doc/html/boost_regex/install.html), additionally you have to download it with synaptic. I guess this second redundant step is neccessary because synaptic may update some system variables (the $PATH???) and install some other dependencies that a direct download from www.boost.org does not do.
I am trying to build a project with the allegro-msvc80-4.2.2 pre-built package. I'm using Visual C++ Express Edition 2005 and have added the input library alld.lib and am including allegro.h asp per these instructions:
http://wiki.allegro.cc/index.php?title=Visual_C%2B%2B_Express_2005
When I compile, I get the fatal error:
C1083: Cannot open include file:
'pc.h': No such file or directory
This is because the allegro platform header file "aldjgpp.h" tries to include the nonexistent file (as well as others such as dpmi.h and unistd.h) if SCAN_DEPEND is undefined.
If I try defining SCAN_DEPEND, I get an error from alconfig.h saying "platform not supported."
That error indicates that you are not using the proper header files. The header files that come with the pre-built files are set appropriately.
You should have an include/allegro/platform/alplatf.h file. For MSVC that should have one line:
#define ALLEGRO_MSVC
The best solution is to delete all instance of Allegro source from your computer, and redownload the file. Be sure to check your compiler's directories for stray headers. The following command, as run from the cmd.exe prompt, will help you find any files.
dir /s c:\allegro.h
If you continue to use the old header files, you may run across other problems.
Also, you may want to consider using Allegro 4.2.3, as it is the latest version of the 4.2 series. (Available at http://www.allegro.cc/files/.)