Cannot find -mpich when using make - makefile

Trying to install this software, and having extracted the tarball, attemping to make I get the error:
/usr/bin/ld: cannot find -lmpich
collect2: error: ld returned 1 exit status
Makefile:162: recipe for target 'N-GenIC' failed
In the Makefile we have:
SYSTYPE="Chris#Adam"
FFTW_INCL = -I/usr/common/pdsoft/include
FFTW_LIBS = -L/usr/common/pdsoft/lib
CC = mpicc # sets the C-compiler (default)
OPTIMIZE = -O3 -Wall # optimization and warning flags (default)
MPICHLIB = -lmpich
#————————————— Adjust settings for target computer
ifeq ($(SYSTYPE),”Chris#Adam”)
CC = mpicc
OPTIMIZE = -O3 -Wall
GSL_INCL = -I/usr/local/include
GSL_LIBS = -L/usr/local/lib
FFTW_INCL= -I/usr/local/include
FFTW_LIBS= -L/usr/local/lib
MPICHLIB = -L/usr/lib
endif
...
LIBS = -lm $(MPICHLIB) $(FFTW_LIB) $(GSL_LIBS) -lgsl -lgslcblas
Now 2 things confuse me about this - I recently intalled GADGET2 which has an almost identical Makefile, also with:
SYSTYPE=”Chris#Adam”
#————————————— Adjust settings for target computer
ifeq ($(SYSTYPE),”Chris#Adam”)
CC = mpicc
OPTIMIZE = -O3 -Wall
GSL_INCL = -I/usr/local/include
GSL_LIBS = -L/usr/local/lib
FFTW_INCL= -I/usr/local/include
FFTW_LIBS= -L/usr/local/lib
MPICHLIB = -L/usr/lib
endif
...
LIBS = $(HDF5LIB) -g $(MPICHLIB) $(GSL_LIBS) -lgsl -lgslcblas -lm $(FFTW_LIB)
so what I don't understand is why is it fine to make GADGET2 but not the other package I'm trying to install? And what's causing the error? I have read some previous questions on this with similar errors and they suggest adding a symlink, but I can't even find where mpich is actually stored, the only executable or symlink i can find is mpicc.

If you're using the mpicc that's provided with MPICH, there's no need to add -lmpich your flags. The mpicc wrapper should take care of all of that for you. If you want to see what mpicc turns into, you can use mpicc -show.

Related

automake putting object files after libraries

src/Makefile.am:
myproj_CXXFLAGS = -fopenmp -O3 -std=c++17 -g -I/home/software/miniconda3/include -I$(top_srcdir)/external
myproj_LDFLAGS = -L/home/software/miniconda3/lib -Wl,-rpath=/home/software/miniconda3/lib -fopenmp -lz -ligraph -pthread
bin_PROGRAMS = myproj
myproj_SOURCES = gfa.cpp graph.cpp myproj.cpp gfa.h graph.h
bindir = $(top_srcdir)/bin
This builds the object files just fine, but when building the target, it tries running
g++ -fopenmp -O3 -std=c++17 -g -I/home/software/miniconda3/include -I../external -g -O2 -L/home/software/miniconda3/lib -Wl,-rpath=/home/software/miniconda3/lib -fopenmp -lz -ligraph -pthread -o myproj myproj-gfa.o myproj-graph.o myproj-komb.o
The issue with this is that the object files come after the library files, which causes the error
/home/software/miniconda3/lib/libz.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
I can easily fix this by adding the -lz -ligraph flags at the very end, but how can I get automake to add the LDFLAGS after the object files as opposed to before?
That's because you're using the wrong variable. To pass libraries, you should use myproj_LDADD, not myproj_LDFLAGS.

no profiling data created while compiling with gcc

I want to use the gprof profiling option in order to speed up my code. I am compiling with gcc. The problem is that there is not output file created 'gmon.out' or so. Here is a sample of the Makefile I am using:
CC = gcc
LD = gcc
#LIBGSL = -L/usr/local/lib -lgsl -lgslcblas
#LIBGSL = -L/usr/lib/x86_64-linux-gnu -lgsl -lgslcblas -lm
#LIBGSL = -L/home/dupont/gsl/gsl-2.4/lib -lgsl -lgslcblas -lm
LIBGSL = -L/n1/soft/64bit/lib -lgsl -lgslcblas -lm
CFLAGSRELEASE = -g -fopenmp -O -Wall -c -pg -I/n1/hhsoft/64bit/include
LFLAGSRELEASE = -g -pg -lm -Wl,--rpath -Wl,/usr/local/lib $(LIBGSL)
CFLAGSDEBUG = -g -p -pg -Wall
LFLAGSDEBUG = -lm
CFLAGSDEBUG = -g -p -pg -Wall -W # -DDEBUG_OUTPUT
LFLAGSDEBUG = -lm -p -pg -Wl,--rpath -Wl,/usr/local/lib $(LIBGSL)
LIBS= -L/home/dupont/folder/soft/pgplot -lm -lcpgplot /home/dupont/folder/soft/pgplot/libpgplot.a -L/usr/X11R6/lib -lX11
CFLAGS = $(CFLAGSRELEASE)
LFLAGS = $(LFLAGSRELEASE)
I don't know much about makefile, do you have any idea of what the problem could be...?
https://sourceware.org/binutils/docs-2.31/gprof/Executing.html
Your program will write the profile data into a file called gmon.out just before exiting
So there's nothing wrong if make produces your program but not gmon.out.
(anyway, you should remove -p, and ensure you use -pg both for compilation and link).

compiling using libnids

I have been trying to install libnids (Ubuntu LTS and Mac OS X) all the day and now I know how to compile programs with it.
I write this here because there is not much documentation but there are samples in the libnids downloaded folder with a makefile. The important things of this makefile are these:
CC = gcc
PCAPLIB = -lpcap
LNETLIB = -lnet
LIBS = -L../src -lnids $(PCAPLIB) $(LNETLIB) -lgthread-2.0 -lnsl
example:
$(CC) example.c -o example $(LIBS)
And if you're compiling it in Mac OS X ignore this: -lgthread-2.0 -lnsl -L../src
But I don't know if something stop to works because of these omitted things.
I found it. The best way is to compile the library and then use local reference to the ".a" file.
Makefile example
CC = gcc -g -Wall
GLIB = `pkg-config --cflags --libs glib-2.0`
PCAPLIB = -lpcap
LNETLIB = -lnet
LIBS_SRC = libnids-1.24/src/libnids.a
LIBS = $(PCAPLIB) $(LNETLIB) -lgthread-2.0
program: program.c
$(CC) -c $(CFLAGS) program.c -o program.o $(GLIB) $(LIBS)
$(CC) program.o -o program $(LIBS_SRC) $(GLIB) $(LIBS)
But if you want to compile the library and install it into your system you got to use -lnids instead of the above way. But the first solution always works.
I got errors when compiling samples under libnids:
gcc -o overflows overflows.o -L../src -lnids -lpcap -lnet -lgthread-2.0 -lnsl ../src/libnids.a
/usr/bin/ld: ../src/libnids.a(libnids.o): undefined reference to symbol 'g_async_queue_pop'
/lib/x86_64-linux-gnu/libglib-2.0.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: * [overflows] Error 1
You recommendation
GLIB = `pkg-config --cflags --libs glib-2.0`
solves my problem.
PS: my system Ubuntu 13.10. 64bit.

gcc and linking files with CFLAGS

I am trying to run program from the Learn C Hard Way book
I need to pass the library filename 'build/liblcthw.a' as the last parameter.
For eg :
Doesnt Work on Ubuntu :
gcc -g -O2 -Wall -Wextra -Isrc -rdynamic -DNDEBUG build/liblcthw.a tests/list_tests.c -o tests/list_tests
Works on Ubuntu :
gcc -g -O2 -Wall -Wextra -Isrc -rdynamic -DNDEBUG tests/list_tests.c -o tests/list_tests build/liblcthw.a
How do I handle this in Makefile ? CFLAGS will only add it before the source filename and it doesnt work. How do I force CFALGS to add the library filename at the end of the command ?
CFLAGS are flags for the C compiler. Libraries typically go into a variable called LDLIBS. Set LDLIBS=build/liblcthw.a and see if that works.
The first invocation doesn't succeed because the order of sources and libraries in the command line is wrong. The correct order is source files, then object files, followed by static libraries followed by dynamic libraries.

Installing PL/Ruby for PostgreSQL 8.3

This is to enable the development of postgres functions with embedded ruby code,
but I have been unable to build it.
As advised by
http://www.robbyonrails.com/articles/2005/08/22/installing-untrusted-pl-ruby-for-postgresql
I am trying to build the needed plruby.so from the latest version (plruby-0.5.3.tar.gz) provided at ftp://moulon.inra.fr/pub/ruby/
I've sorted out where my local postgres set up is and adjusted the invocation to:
ruby extconf.rb --with-pgsql-include=/usr/postgresql-8.3.4/include/server --enable-shared --disable-conversion --with-pgsql-version=83
I've tried quite number of variations on that, but it does not seem to be able to successfully make
the 'conftest.c' file
It says this:
checking for catalog/pg_proc.h... yes
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers. Check the mkmf.log file for more
details. You may need configuration options.
And here is what I end up with in my mkmf.log
have_header: checking for catalog/pg_proc.h... -------------------- yes
"gcc -E -I. -I/usr/lib/ruby/1.8/x86_64-linux -I. -I/usr/postgresql-8.3.4/include/server -g -O2 -fPIC conftest.c -o conftest.i"
checked program was:
/* begin */
1: #include <catalog/pg_proc.h>
/* end */
When I run the gcc line manually, it says there is no 'conftest.c' (and there is not, but
it is supposed to be generated).
'uname -a' ... gives
Linux vdev1 2.6.18.8-xen #2 SMP Thu May 8 11:52:29 PDT 2008 x86_64 x86_64 x86_64 GNU/Linux
'ruby -v' ... gives
ruby 1.8.6 (2008-08-11 patchlevel 287) [x86_64-linux]
Any help and/or advice would be appreciated.
-- Mike Berrow
OK, I managed to hand build this (bypassing the fragile extconf.rb and makefile) by googling for a logfile of
a successful build, starting with the gcc lines I saw there, then fiddling with the gcc compile
flags and paths until it worked.
In plruby.h change the SAFE_LEVEL to 0
as shown below
#ifndef SAFE_LEVEL
//#define SAFE_LEVEL 12
#define SAFE_LEVEL 0
#endif
Compile each from shell then link
gcc -I. -I. -I/usr/lib/ruby/1.8/x86_64-linux -I. -DHAVE_CATALOG_PG_PROC_H -DHAVE_RB_HASH_DELETE -DHAVE_ST_H -DHAVE_UTILS_ARRAY_H -I/usr/postgresql-8.3.4/include/server -D_FILE_OFFSET_BITS=64 -fPIC -fno-strict-aliasing -g -g -O2 -fPIC -DHAVE_RB_HASH_DELETE -DHAVE_RB_INITIALIZE_COPY -DPG_UTILS_ARRAY -DPG_PL_TRYCATCH -DPG_PL_VERSION=83 -DPLRUBY_CALL_HANDLER=plruby_call_handler -DPLRUBY_VALIDATOR=plruby_validator -c plruby.c
gcc -I. -I. -I/usr/lib/ruby/1.8/x86_64-linux -I. -DHAVE_CATALOG_PG_PROC_H -DHAVE_RB_HASH_DELETE -DHAVE_ST_H -DHAVE_UTILS_ARRAY_H -I/usr/postgresql-8.3.4/include/server -D_FILE_OFFSET_BITS=64 -fPIC -fno-strict-aliasing -g -g -O2 -fPIC -DHAVE_RB_HASH_DELETE -DHAVE_RB_INITIALIZE_COPY -DPG_UTILS_ARRAY -DPG_PL_TRYCATCH -DPG_PL_VERSION=83 -DPLRUBY_CALL_HANDLER=plruby_call_handler -DPLRUBY_VALIDATOR=plruby_validator -c plplan.c
gcc -I. -I. -I/usr/lib/ruby/1.8/x86_64-linux -I. -DHAVE_CATALOG_PG_PROC_H -DHAVE_RB_HASH_DELETE -DHAVE_ST_H -DHAVE_UTILS_ARRAY_H -I/usr/postgresql-8.3.4/include/server -D_FILE_OFFSET_BITS=64 -fPIC -fno-strict-aliasing -g -g -O2 -fPIC -DHAVE_RB_HASH_DELETE -DHAVE_RB_INITIALIZE_COPY -DPG_UTILS_ARRAY -DPG_PL_TRYCATCH -DPG_PL_VERSION=83 -DPLRUBY_CALL_HANDLER=plruby_call_handler -DPLRUBY_VALIDATOR=plruby_validator -c plpl.c
gcc -I. -I. -I/usr/lib/ruby/1.8/x86_64-linux -I. -DHAVE_CATALOG_PG_PROC_H -DHAVE_RB_HASH_DELETE -DHAVE_ST_H -DHAVE_UTILS_ARRAY_H -I/usr/postgresql-8.3.4/include/server -D_FILE_OFFSET_BITS=64 -fPIC -fno-strict-aliasing -g -g -O2 -fPIC -DHAVE_RB_HASH_DELETE -DHAVE_RB_INITIALIZE_COPY -DPG_UTILS_ARRAY -DPG_PL_TRYCATCH -DPG_PL_VERSION=83 -DPLRUBY_CALL_HANDLER=plruby_call_handler -DPLRUBY_VALIDATOR=plruby_validator -c pltrans.c
gcc -shared -o plruby.so plruby.o plplan.o plpl.o pltrans.o -L. -L/usr/lib -L/usr/postgresql-8.3.4/lib -L. -Wl,-Bsymbolic -rdynamic -Wl,-export-dynamic -lruby -lpthread -ldl -lcrypt -lm -lc
Place the '.so' file built above in the dynamic library path ($libdir)
[ determined using pg_config --pkglibdir giving (in my case) /usr/postgresql-8.3.4/lib ]
Others taking this approach will most likely have to do their own tweaking.
Add these functions ...
CREATE OR REPLACE FUNCTION plruby_call_handler()
RETURNS language_handler AS
'$libdir/plruby', 'plruby_call_handler'
LANGUAGE 'c' VOLATILE
COST 1;
ALTER FUNCTION plruby_call_handler() OWNER TO postgres;
CREATE OR REPLACE FUNCTION plruby_validator(oid)
RETURNS void AS
'$libdir/plruby', 'plruby_validator'
LANGUAGE 'c' VOLATILE
COST 1;
ALTER FUNCTION plruby_validator(oid) OWNER TO postgres;
Add 'plruby' as a procedural language
CREATE PROCEDURAL LANGUAGE 'plruby' HANDLER plruby_call_handler;
Test it:
CREATE FUNCTION ruby_max(int4, int4) RETURNS text AS '
if args[0].to_i > args[1].to_i
return "The one on the left is bigger"
else
return "The one on the right is bigger"
end
' LANGUAGE 'plruby';
select ruby_max(8, 9);
There are other build options for this that enable type 'conversions'.
The above build is the simplest one and all function parameters actually
come into ruby as strings (even though they are declared as int4).
Thus the need for the 'to_i' call here.

Resources