mt19937 is not a member of std possible makefile issue - makefile

In my program I use std::mt19937 to generate random numbers. On two systems (latest windows and ubuntu) the program compiles fine. But, on a third unknown system (using make) I get the error message:
" 'mt19937' is not a member of 'std' "
I am assuming the makefile isn't written correctly. I am new to makefiles and not sure where to start. Do I need to enforce c++11? How would I do so?
all:
%.o: %.cc
g++ -c -O2 -Wall -Wextra -pedantic $<
library-objects = \
BigUnsigned.o \
BigInteger.o \
BigIntegerAlgorithms.o \
BigUnsignedInABase.o \
BigIntegerUtils.o \
library-headers = \
NumberlikeArray.hh \
BigUnsigned.hh \
BigInteger.hh \
BigIntegerAlgorithms.hh \
BigUnsignedInABase.hh \
BigIntegerLibrary.hh \
library: $(library-objects)
$(library-objects): $(library-headers)
# Components of the program.
program = rsa435
program-objects = rsa435.o
$(program-objects) : $(library-headers)
$(program) : $(program-objects) $(library-objects)
g++ $^ -o $#
clean :
rm -f $(library-objects) $(testsuite-cleanfiles) $(program-objects) $(program)
all : library $(program)
EDIT: It might be worth mentioning that I have both cc files and cpp files. Maybe this is causing an issue as well?

The error is saying is that it knows about the "std" namespace but there is no "mt19937" defined in that namespace.
Add "-std=c++11" to your g++ command line because mt19937 wasn't defined until C++11.
(Credit: this was originally posted by Richard Critten as a comment to the question.)
Also, you might need to add this header file:
#include <random>

"-std=c++11" is not enough , add #include<bits/stdc++.h>

Related

Difference between preprocessor macros D__KERNEL__ and __KERNEL__

I am an absolute beginner in programming in linux kernel programming, so sorry if the question is to elementary.
Here https://www.oreilly.com/library/view/linux-device-drivers/0596000081/ch02s02.html I found following example:
# Change it here or specify it on the "make" command line
KERNELDIR = /usr/src/linux
include $(KERNELDIR)/.config
CFLAGS = -D__KERNEL__ -DMODULE -I$(KERNELDIR)/include \ -O -Wall
ifdef CONFIG_SMP
CFLAGS += -D__SMP__ -DSMP
endif
all: skull.o
skull.o: skull_init.o skull_clean.o
$(LD) -r $^ -o $#
clean:
rm -f *.o *~ core
And my question is simply what is the difference between preprocessor macro __KERNEL__ and the used -D__KERNEL__? Especially what is the meaning of "-D" here? (by the way the same story with MODULE and -DMODULE).
-D is an option to the compiler (or preprocessor), telling it to define a macro. So putting -D__KERNEL__ on the compiler command line is exactly the same as putting #define __KERNEL__ at the top of the file. Likewise, -DFOO would define a macro named FOO.
No macro named D__KERNEL__ is being defined anywhere here.

Compiling Fortran 77 with an external library using a Makefile

I have main program Engine.f that calls functions/external in LIB.f.
Unlike C++ and Java there is no include in the main program so it will be possible to compile.
How does my Fortran comiler know that there is another library which I use?
I'm using photran from Eclipse.
The MAKE file:
.PHONY: all clean
# Change this line if you are using a different Fortran compiler
FORTRAN_COMPILER = gfortran
all: src/Engine.f
$(FORTRAN_COMPILER) -O2 -g \
-o bin/Engine.exe \
src/Engine.f
clean:
rm -f bin/Engine.exe *.mod
errors that I get when I compile:
undefined reference to (name of function in **LIB.f**)
.PHONY: all clean
all: Engine.exe
# Change this line if you are using a different Fortran compiler
FORTRAN_COMPILER = gfortran
FORTRAN_FLAGS=-O2 -g
%.o: src/%.f
$(FORTRAN_COMPILER) $(FORTRAN_FLAGS) -c $<
Engine.exe: Lib.o Engine.o
$(FORTRAN_COMPILER) $(FORTRAN_FLAGS) \
-o bin/Engine.exe \
Lib.o Engine.o
clean:
rm -f *.o *.mod
In FORTRAN 77, the compiler "just" needs the function to be supplied in a .o file at link time. You can test the Makefile below, it should do what you want.
Modern versions of Fortran use module files to structure libraries, if you ever upgrade to that.

linking error interfacing ocaml for windows with external c library

I am developing a project in ocaml that requires me to interface it with the OGDF external c++ library. It is all up and running on my mac, but now I am trying to create a windows version using Ocaml for Windows (https://fdopen.github.io/opam-repository-mingw/), the MinGW Cygwin port of Ocaml. In this version, I can interface ocaml with c code and it works fine, but as soon as I try to include an external library in that c code I get errors from the linker, which is flexdll (https://github.com/alainfrisch/flexdll) in this case. The linker says it cannot resolve symbols for _Unwind_Resume and __emutls_get_address throughout the library.
Here is a toy example:
My .ml file t.ml:
external print : unit -> unit = "print"
let () =
Printf.printf "platform: %s\n" (Sys.os_type);
print ()
My .cpp file tc.cpp:
#include <stdio.h>
#include "caml/mlvalues.h"
#define CAML_NAME_SPACE
//#include <ogdf/basic/Graph.h>
extern "C" value print(value unused) {
printf("hello from C\n");
return Val_unit;
}
My makefile:
t.exe: t.ml tc.o
ocamlopt -verbose -ccopt -pthread \
-cclib -lstdc++ -w s \
-ccopt -L../cdeg/ogdf/_release \
-cclib -lOGDF \
tc.o t.ml \
-o t.exe
tc.o: tc.cpp
x86_64-w64-mingw32-gcc -c \
-march=x86-64 -mtune=generic -O2 -mms-bitfields -Wall -Wno-unused \
tc.cpp \
-I../cdeg/ogdf -L../cdeg/ogdf/_release -lOGDF \
-I ~/.opam/4.04.0+mingw64c/lib/ocaml \
-lstdc++ -pthread -o tc.o
Like this, it all compiles happily, but if I uncomment the ogdf include line in tc.cpp, I get the following output:
$ make
x86_64-w64-mingw32-gcc -c \
-march=x86-64 -mtune=generic -O2 -mms-bitfields -Wall -Wno-unused \
tc.cpp \
-I../cdeg/ogdf -L../cdeg/ogdf/_release -lOGDF \
-I ~/.opam/4.04.0+mingw64c/lib/ocaml \
-lstdc++ -pthread -o tc.o
ocamlopt -verbose -ccopt -pthread \
-cclib -lstdc++ -w s \
-ccopt -L../cdeg/ogdf/_release \
-cclib -lOGDF \
tc.o t.ml \
-o t.exe
+ x86_64-w64-mingw32-as -o "t.o" "C:\OCaml64\tmp\camlasme5f9bd.s"
+ x86_64-w64-mingw32-as -o "C:\OCaml64\tmp\camlstartupf2b3f1.o" "C:\OCaml64\tmp\camlstartup101e51.s"
+ flexlink -chain mingw64 -stack 33554432 -exe -o "t.exe" "-LC:/OCaml64/home/Nathaniel.Miller/.opam/4.04.0+mingw64c/lib/ocaml" -pthread -L../cdeg/ogdf/_release "C:\OCaml64\tmp\camlstartupf2b3f1.o" "C:/OCaml64/home/Nathaniel.Miller/.opam/4.04.0+mingw64c/lib/ocaml\std_exit.o" "t.o" "C:/OCaml64/home/Nathaniel.Miller/.opam/4.04.0+mingw64c/lib/ocaml\stdlib.a" "-lstdc++" "-lOGDF" "tc.o" "C:/OCaml64/home/Nathaniel.Miller/.opam/4.04.0+mingw64c/lib/ocaml\libasmrun.a" -lws2_32
** Cannot resolve symbols for ../cdeg/ogdf/_release\libOGDF.a(PoolMemoryAllocator.o/
PreprocessorLayout.o/
extended_graph_alg.o/
graph_generators.o/
random_hierarchy.o/
simple_graph_alg.o/
CPlanarEdgeInserter.o/
... [a bunch of other .o files from the library]...
UpwardPlanarModule.o/
UpwardPlanarSubgraphModule.o/
UpwardPlanarSubgraphSimple.o/
VisibilityLayout.o/
):
_Unwind_Resume
__emutls_get_address
** Cannot resolve symbols for ../cdeg/ogdf/_release\libOGDF.a(basic.o):
_Unwind_Resume
File "caml_startup", line 1:
Error: Error during linking
make: *** [makefile:20: t.exe] Error 2
If I don't connect it to ocaml, but instead add a main() function to t.c it compiles just fine under x86_64-w64-mingw32-gcc with the external library included. I've tried including a few other small external libraries and they didn't cause this problem.
My first thought was that maybe the problem had to do with the linked files not all being compiled the same way, but I compiled the library and the .cpp file with the compiler and options given by ocamlopt -configure. And if they weren't all compiled the same way, I wouldn't expect to be able to get tc.cpp to work individually with ocamlopt and with the external library, but I only get errors when I try to use both. So is this an issue with Ocaml for windows, or flexdll, or with my installation of one of these? I'm at a loss for what to try next, and any ideas, suggestions, and/or explanations of what is going on here would be very much appreciated.
I have a partial answer. The issue is coming somehow from flexdll. I switched to using the Cygwin version of ocaml with gcc, and still had the same problem. Then I recompiled ocaml configured with the -no-shared-libs flag, which makes ocamlopt link with gcc instead of flexdll, and now everything compiles.

makefile explicitly linking multiple dynamic libraries

I'm trying to put together a simple makefile example like so:
FLAGS = -std=c++14
INC= -I/usr/local/include
LI = -L/usr/local/lib
LIB = /usr/local/lib/
LIBS = $(LIB)libboost_filesystem-mt.a \
$(LIB)libboost_filesystem-mt.dylib \
$(LIB)libboost_filesystem.a \
$(LIB)libboost_filesystem.dylib \
$(LIB)libboost_system-mt.a \
$(LIB)libboost_system-mt.dylib \
$(LIB)libboost_system.a \
$(LIB)libboost_system.dylib
default:
g++ main.cpp $(FLAGS) $(INC) $(LI) $(LIBS) -o assemble
./assemble
clean:
rm assemble
Is there a way to not have to prepend $(LIB) so many times? That's the only way I can get this to work right now (the above doesn't).
If you want the linker to search the path you have to add libraries using the -l flag. So instead of adding libboost_system-mt.a to your link line, you have to add -lboost_system-mt to your link line. Then the linker will search the paths provided by -L.
I'm not sure about the dylib stuff; I don't do much with OS X.
In any event, if you're using GNU make you can do this:
LIBNAMES := filesystem-mt filesystem system-mt system
LIBS := $(foreach N,$(LIBNAMES),$(LIB)libboost_$N.a $(LIB)libboost_$N.dylib)

Error while loading shared libraries: liblua.so

I'm trying to launch a client for a school project that has an AI developed in Lua, I have added liblua.so in a /lib/ folder at the root of my program's folder.
After compiling and launching said program, I get the following error:
./zappy_ai: error while loading shared libraries: liblua.so: cannot open shared object file: No such file or directory
From what I understand I must do something at the compilation for my program to know where my shared library is located.
Here's the relevant part of my Makefile:
CXX = g++
BASE_FLAGS = -Wall -Wextra -Iincludes
AI_NAME = zappy_ai
AI_PATH = ./sources/client/
AI_FLAGS = $(BASE_FLAGS) \
-L./lib/ \
-I./includes/client/ \
-I./include/ \
-std=c++11 \
AI_LDFLAGS = -llua
AI_SRCS = main.cpp \
Client.cpp \
Params/Params.cpp \
Params/Option.cpp \
SocketTCP.cpp \
Misc/Error.cpp
AI_OBJS = $(addprefix $(AI_PATH), $(AI_SRCS:.cpp=.cpp.o))
%.cpp.o : %.cpp
#printf "%b[Compilation]%b %-50s" $(BLUE) $(RESET) $<
#$(CXX) $(FLAGS) -c $< -o $#
#printf "%bOK%b\n" $(GREEN) $(RESET)
$(AI_NAME) : FLAGS = $(AI_FLAGS)
$(AI_NAME) : $(AI_OBJS)
#$(CXX) $^ -o $# $(AI_LDFLAGS)
#printf "%b[Message]%b AI compilation done\n\n" $(YELLOW) $(RESET)
What should I add in order to be able to launch my program and have it find my shared library?
tldr:
$ LD_LIBRARY_PATH="$LD_LIBRARY_PATH:./lib" ./zappy_ai
Longer explanation:
You've dynamically linked
zappy_ai
against
./lib/liblua.so
by using
LDFLAGS = -L./lib/
and
LDLIBS = -llua
The resulting zappy_ai executable requires that same ./lib/ to be present within the LD_LIBRARY_PATH environment variable when the dynamic linker/loader attempts to resolve the -llua symbols that zappy_ai uses.

Resources