cannot find -lX11 on windows MSYS - makefile

I'm trying to compile a program that uses some X11 plotting window files.
I downloaded the files from https://www.x.org/releases/X11R6/ and extracted them to a folder that is known.
As part of this process, I have two Makefile files (A and B).
Makefile B produces the library libPlt_gfortran.a without any errors.
Makefile A is supposed to compile some FORTRAN code and create an .exe file.
In Makefile A, I have the following lines that refer to some X11 library.
PLTOBJ = ../plotlib/libPlt_gfortran.a
PLTLIB = -L/usr/X11R6/lib -lX11
However, despite setting PLTLIB to the folder containing the extracted X11R6 files, I keep getting the following error when I try to make my program.
c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe: cannot fin
d -lX11
collect2.exe: error: ld returned 1 exit status
I keep seeing people with very similar issues for this, as well as numerous fixes, however none of them are for windows users. Using linux/ubuntu is not an option at the moment as computers are all windows based and students cannot install any other operating system...
Current path of /usr/ folder on the Windows PC/usr/ path

Related

What is causing g++ to produce the error: "ld.exe cannot find -lopencv_world310"?

I am attempting to build an application using g++ that is composed of several source files and also uses OpenCV 3.1.0.
The CMD command is:
g++ -o home_surveillance -static -std=c++11 -m64 -IC:\Tools\OpenCV\opencv\build\include -LC:\Tools\OpenCV\opencv\build\x64\vc14\lib -lopencv_world310 configuration_manager.cpp events.cpp image_processor.cpp main.cpp response_module.cpp scheduler.cpp
The error produced is:
C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lopencv_world310
collect2.exe: error: ld returned 1 exit status
I have been trying various things and searching for answers for a couple days now. I should note that the application builds properly in Visual Studio 2015. I have tried compiling the source files using g++ with the -c option and they all seem to compile fine. It is just the linking phase that produces an error.
Things I have tried:
Just about every possible combination of the specified command. (Modifying order of the options, -lopencv_world310.a, -lopencv_world310.lib, -lopencv_world310, -l"full_path"+"opencv_world310", etc..)
Checked that all the paths and filenames are correct.
Reinstalled mingw to make sure I was using mingw-w64 since this is a 64-bit application.
Running CMD as admin thinking maybe CMD could not access the path specified with -L option.
Googling and reading every post I could find. (Most posts about "ld.exe cannot find "library_name" are a result of someone using "library_name".a or "library_name".lib as input to the -l option).
Reading mingw documentation on the use of GCC/g++ to ensure I wasn't missing anything obvious.
Praying to Bjarne Stroustrup.
Ritual sacrifice involving a Pentium 2.

g++: link to non-standard /usr/local

I have an OSX 10.7 computer with a non-administrator account, and was attempting to install the pre-compiled versions of gcc and g++ found here. I've attempted to use the answers presented in these questions (three different links) to compile some code with g++, to confusing avail. I have a folder structure like this:
~/code/:
usr/:
local/:
bin/ (3.6MB)
include/ (8.6MB)
lib/ (51MB)
libexec/ (49MB)
share/ (16MB)
c++/:
source/ (contains .cpp files)
g++ -v returns this:
code USER$ usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=usr/local/bin/g++
COLLECT_LTO_WRAPPER=/Users/USERNAME/code/usr/local/bin/../libexec/gcc/ x86_64-apple-darwin11.4.0/4.7.1/lto-wrapper
Target: x86_64-apple-darwin11.4.0
Configured with: ../gcc-4.7.1/configure --enable-languages=fortran
Thread model: posix
gcc version 4.7.1 (GCC)
An attempt at compiling a file that "#include"s only iostream:
$ usr/local/bin/g++ c++/source/test.cpp -o ex6
In file included from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/bits/postypes.h:42:0,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/iosfwd:42,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/ios:39,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/ostream:40,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/iostream:40,
from c++/source/ex6.cpp:1:
/Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/cwchar:46:19: fatal error: wchar.h: No such file or directory
compilation terminated.
I tried compiling with some flags recommended in one of the links mentioned, like this: (with all combinations of "usr/" to "usr/local/include/" and "usr/" to "/usr/local/lib" giving the same result (which is also the same as using no flags).
$ /Users/USERNAME/code/usr/local/bin/g++ source/ex6.cpp -I/Users/USERNAME/code/usr/local/include/ -L/Users/USERNAME/code/usr/local/lib/In file included from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/bits/postypes.h:42:0,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/iosfwd:42,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/ios:39,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/ostream:40,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/iostream:40,
from source/ex6.cpp:1:
/Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/cwchar:46:19: fatal error: wchar.h: No such file or directory
compilation terminated.
In short, I'm having trouble understanding what the answers in the links provided are saying to do. I saw reference to a specs file, which I could find no specific information for, and "-Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)", for which I couldn't figure out what I was supposed to substitute for "DEFAULT_LIB_INSTALL_PATH".
What should I do to point the downloaded g++ compiler to its own files without placing them in their default location, as I do not have administrative capabilities on this account?
I will provide any information as necessary.
It looks like you don't have required header files. You need to install Command Line Tools from Apple Developers site (free registration needed). The problem is that you don't have administrator account. I suggest that you ask the administrator to install the tools for you. If it is not possible you could try to extract the contents of downloaded package (DevSDK.pkg) to your local directory (Pacifist can do that) and pass the path with the missing headers to your compiler. I haven't tried that though.

Use HDF5 from minGW on windows

I'm trying to compile and link to HDF5 with a Fortran program, but I'm getting a run-time error. I've followed closely the procedure described in the answer to this question
Use HDF5 from intel fortran on windows
I've set PATH in the environment variables instead of setting them in visual studio. I moved all of the generated .mod and .lib files to the mod and lib folders in my project folder.
From the command prompt, my compiler config looks like
gfortran --version
GNU Fortran (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.2
gmake --version
GNU Make 3.81
And my makefile looks like
ifdef SystemRoot
PATHSEP2 = \\
else
PATHSEP2 = /
endif
PS = $(strip $(PATHSEP2))
OBJ_DIR = obj
MOD_DIR = mod
LIB_DIR = lib
FC = gfortran
FCFLAGS = -I$(MOD_DIR) -g -Wall
FLFLAGS = -I$(MOD_DIR) -L$(LIB_DIR) -l$(LIB_DIR)hdf5_fortran
SRCS_F = testHDF5.f90
TARGET = testHDF5
all: $(TARGET)
testHDF5: testHDF5.f90
$(FC) -o $# testHDF5.f90 $(FLFLAGS)
$(OBJ_DIR)$(PS)%.o: %.f90
$(FC) $(FCFLAGS) -c -o $# $<
I've changed the hdf5_fortran.lib to libhdf5_fortran.lib because of what I read here
http://www.mingw.org/wiki/specify_the_libraries_for_the_linker_to_use
When I run gmake, I get
gfortran -o testHDF5 testHDF5.f90 -Imod -Llib -llibhdf5_fortran
And when I try to run the executable, a window pops up that says "The application was unable to start correctly (0xc000007b). Click OK to close the application."
This link
http://www.solveinweb.com/solved-the-application-was-unable-to-start-correctly-0xc000007b-click-ok-to-close-the-application/
Suggests that it is due to incompatibility of 32-bit to 64-bit. I'm using a 64-bit machine, and I did download a 32-bit version of CMake, but only because there doesn't seem to be an available version for 64-bit machines. In addition, this link
http://www.cmake.org/pipermail/cmake/2010-September/039375.html
Suggests that it shouldn't matter. So my question is, where did I go wrong? Are there any glaring mistakes with what I've shown so far?
UPDATE:
I found out that the runtime error was due to not specifying a path, in this case HDF5_DIR. In the USING_HDF5_CMAKE document, it says to specify the environment variable
HDF5_DIR=C:/Program Files/HDF_Group/HDF5/1.8.x/cmake/hdf5
Which fixed the problem of the application crashing at the very start. But now, I'm getting the error
HDF5-DIAG: Error detected in HDF5 (1.8.14) thread 0:
#000: C:\Users\Charlie\Downloads\CMake\hdf5-1.8.14\src\H5D.c line 167 in H5Dcr
eate2(): not a datatype ID
major: Invalid arguments to routine
minor: Inappropriate type
HDF5-DIAG: Error detected in HDF5 (1.8.14) thread 0:
#000: C:\Users\Charlie\Downloads\CMake\hdf5-1.8.14\src\H5D.c line 415 in H5Dcl
ose(): not a dataset
major: Invalid arguments to routine
minor: Inappropriate type
I suppose the first error
HDF5-DIAG: Error detected in HDF5 (1.8.14) thread 0:
#000: C:\Users\Charlie\Downloads\CMake\hdf5-1.8.14\src\H5D.c line 167 in H5Dcr
eate2(): not a datatype ID
major: Invalid arguments to routine
minor: Inappropriate type
Is the most important one since that may trigger later ones. According to this thread
http://hdf-forum.184993.n3.nabble.com/HDF5-Fortran-Fail-to-execute-of-a-basic-F90-program-td4026778.html
It is suggested that the same compiler is used to build the library as building the fortran source code (if I'm not mistaken). During the build using CMake, I specified to use MinGW, which I believe is used during both builds, right?
Again, any help on this is greatly appreciated.
I contacted hdf5 support in regards to this problem
Platform/OS:
Windows 7
Product/Version:
HDF5, Latest download
Description:
Hi, I'm having trouble getting HDF5 working on my windows machine with fortran. Below is an outline of what I've done, and after I show the error I get.
1.1) Download and install CMake, Windows (Win 32 Installer) from http://www.cmake.org/download/
1.2) I did not add CMake to the system PATH, because it was too long.
1.3) I manually added "C:/Program Files (x86)/CMake/bin" to the PATH (for user)
in computer->properties->advanced system settings->environment variables 2.1) Download and install HDF5
2.2) I manually added "C:/Program Files/HDF Group/HDF5/1.8.14/cmake/hdf5" to the PATH (for user) in computer->properties->advanced system settings->environment variables
3.1) I created a new, empty, directory (/Project/) and copied HDF5Examples-0.1.1-Source.zip and HDF518 Examples.CMAKE to it. 3.1) Downloaded hdf5-CMakeWindows.zip from http://www.hdfgroup.org/HDF5/release/cmakebuild.html and unzipped
file to find a folder named CMake.
3.2) Opened CMake GUI, set Source Code Dir = CMake/hdf5-1.8.14 folder
3.3) Set Where to build binaries Dir = /Project/ (project folder containing HDF5Examples-0.1.1-Source.zip and HDF518 Examples.CMAKE)
4.1) In the CMake GUI, I pressed Configure, (selected MinGW and default from the 1st and 2nd drop down respectively), Configure. Checked BUILD_SHARED_LIBS and HDF5_BUILD_FORTRAN. Configure, configure, generate.
4.2) I navigated to the bin directory of the CMake folder and copied the library files, .dll files, and .mod files to an empty test folder (/test_HDF5/), where I separated them into lib/mod folders.
4.3) I created a makefile which, if done correctly, linked the .lib files.
4.4) I compiled the files and linked the libraries and there seemed to be no errors, nor warnings. When running the testHDF5.exe I received the following error: The application was unable to start correctly (0xc000007b). Click OK to close the application. I believe this is a configuration issue, and I'm not sure how to resolve it.
I'm very new with linking libraries and I'm just trying to use HDF5 as a data exporting tool with my existing fortran code. Any help is greatly appreciated.
Sincerely, Charlie Kawczynski
And their response was, as of April 14 2015, that MinGW is not supported:
Hi Charlie,
We do not support MinGW at this time. The developer had tried
building with Fortran and was not able to get it to work.
We do have a user forum where you can post questions. However, others
have posted issues about MinGW and Fortran that have not been resolved. :(
For information on the HDF Forum, see:
http://www.hdfgroup.org/services/community_support.html
-Barbara
Hope this helps others.

cross gcc crti.o

I have followed the instructions at Cross linux from scratch for powerpc, but I can't get past the gcc-final stage due to an ld error crti.o: no such file or directory.
My tool chain is separated into two directories: /opt/builder/tools and /opt/builder/cross-tools, with Linux headers and eglibc in the first and cross-utilities in the second. Also I have created links /tools and /cross-tools for those directories.
I have tried /cross-tools/bin/powerpc-unknown-linux-gcc -print-search-path and there was a directory /opt/builder/tools/lib there in the "libraries" section. But gcc passes names of crt....o objects to ld without directory prefixes (I have used strace to find it out).
The crt....o files are good because, when I copied them to the directory with hello.c and compiled it, everything was ok.
Could you give some advice?
Thanks in advance,
Sergey Naumov.
The libc-provided crt files should be in $ROOT/$TARGET/lib/ (i.e., The gcc-compiled crt files will later be installed in $ROOT/lib/gcc/$TARGET/$GCC_VERSION/.

Using Boost with Cygwin on Windows

This shoud be a simple problem for users more advanced than I am. :-)
How do I use the boost library with cygwin on windows?
I am programing with g++ using cygwin on a winxp machine.
I need modified Bessel functions of the second order, so I downloaded the latest version of the boost library and installed it in
'c:\cygwin\lib\boost_ 1_ 38_0\' folder.
I am trying to run the "example.cpp" program from the "getting started" section of their website:
http://www.boost.org/doc/libs/1_35_0/more/getting_started/unix-variants.html
I am compiling from the directory where I created the example file using a simple Bash shell command line: 'g++ -Wall example.cpp'
I keep getting the message:
"boost/lambda/lambda.hpp: no such file or directory"
I tried every possible combination of -L, -l, -I options in the command line to include the directory, to no avail. Also tried to add the folder in the PATH line of my windows system.
How do I link to the /boost directory and ALSO to all subdirectories? The header file 'lambda.hpp' is calling other header files in subdirectories.
You're probably not that familiar with C++ yet? It seems you are confusing terms.
C++ programs are built in two steps: compiling and linking. In the first step, each source file (typically called .cpp) is handled individually. Each .cpp file usually uses multiple headers, so the compiler first inserts those - literally. That's why it's called #include.
In the second step, the linker takes all the compiled .cpp files together and builds your final program. Some of those compiled .cpp's might have been bundled together before, in which the bundle is called a library.
Boost is a collection of headers and .cpp files. So, both compiler and linker might need to find the Boost directories. From your error message, it's clear that the compiler step is the problem. The linker does not need headers anymore.
The compiler will see the #include <boost/lambda/lambda.hpp> instuction. That means it needs to know where that first-level boost directory is found. I would guess at this point that the path would be /lib/boost_ 1_ 38_0/include (there's always the find / -name lambda.hpp shotgun appraoch)
If you are not utterly wedded to cygwin, you should take a look at http://nuwen.net/mingw.html which gives you a complete MinGW C++ installation with all the libraries (such as Boost) set up for you.
Edit: I should make it clear you can use this MinGW installation in addition to Cygwin, not as a replacement. Just make sure the MinGW bin directory appears in your PATH before the Cygwin one.
I think you need -I /lib/boost_1_38_0 - although that's a pretty unusual place to put it. You'll have to let us know how you installed it, did you just unzip it in the location you said, or did you run the makefiles? I assume that since you gave a windows path you didn't install it within cygwin - which you probably should do. The instructions in the getting started guide for unix should help - although don't download a prebuilt bjam - it needs to be built with cygwin.
But if you're not very familiar with cygwin (or unix in general) I think you might find it easier to use a native windows tool - as in Neil Butterworth's answer.
Thank you all for the information, it's a nice introduction to the use of libraries with cygwin.
Daniel was right. While any variation gives an error, the following line (using caps i) does the trick:
g++ -Wall -I /cygdrive/c/cygwin/lib/boost_1_38_0/ example.cpp -o example
I will also check MinGW in the next few days.
p.s. I simply downloaded and unzipped boost in that folder, but since I am only using header files I probably won't need to compile with cygwin. [The boost version included with cygwin was 1.33, which does not seem to have Bessel functions.]
This is on win7 cygwin64 g++ 5.4, and boost-1.64.7z on 2017-7. Google doesn't show any useful result for getting started for boost on windows (is boost out of fashion?).
By experimenting, I managed to compile and run a boost graph sample program as follows:
:: g++ 5.4 in c:\cygwin64
:: 7z extract boost download in c:\tools\boost\boost164
> set BOOST_ROOT=c:\tools\boost\boost164
> setx BOOST_ROOT c:\tools\boost\boost164 -m
> cd %BOOST_ROOT%
> bootstrap.sh gcc (the bat files doesn't work)
> b2.exe
...failed updating 58 targets...
...skipped 18 targets...
...updated 1123 targets...
:: Lots of example here (not ranked highly by google)
> mklink /D eg %BOOST_ROOT%/libs/graph/example
:: Compiled and run [maxflow code using boost library][1]
:: http://vision.csd.uwo.ca/code
> unzip ; vi Makefile
CPPFLAGS = -I %BOOST_ROOT%/
LDFLAGS = -L%BOOST_ROOT%/stage/lib
> make
> set PATH=%PATH%;%BOOST_ROOT%/stage/lib
> maxflow.exe
Flow = 6

Resources