I'm trying to build a Fortran model with Parallel IO (1.7.2) included. But I got numerous errors like these:
pionfwrite_mod.F90:(.text+0x1bad): undefined reference to `nfmpi_iput_vara_'
pionfwrite_mod.F90:(.text+0x21ad): undefined reference to `__netcdf_MOD_nf90_put_var_1d_fourbyteint'
pionfwrite_mod.F90:(.text+0x22a9): undefined reference to `__netcdf_MOD_nf90_inquire_variable'
pionfwrite_mod.F90:(.text+0x27e5): undefined reference to `__netcdf_MOD_nf90_put_var_1d_fourbyteint'
pionfwrite_mod.F90:(.text+0x2ad7): undefined reference to `__netcdf_MOD_nf90_put_var_1d_fourbyteint'
I googled and found some possible solutions, for example, https://www.myroms.org/wiki/Frequently_Asked_Questions#Errors_at_link_time, but I still cannot solve my problem.
Questions: is this a library linking problem? if not, could you please give me some suggestions on how to debug? If so, could you please share the detailed steps on how to link the library? Thank you.
Environment libraries: PnetCDF 1.8.1, netCDF 4.5.1, Parallel IO 1.7.2, gcc 7.1.1, openmpi-2.0.2-2.fc26.x86_64
I solved my problem by checking the library path and install earlier versions of netcdf and pnetcdf in local folders.
The makefile from this MPAS model sets netcdf path and library as follows:
ifneq "$(NETCDF)" ""
CPPINCLUDES += -I$(NETCDF)/include
FCINCLUDES += -I$(NETCDF)/include
LIBS += -L$(NETCDF)/lib
NCLIB = -lnetcdf
NCLIBF = -lnetcdff
...
endif
while for linux F26, it seems the netcdf installed using DNF (not sure if DNF is the reason though) does not build a separate folder to put all related files under $NETCDF, the related files are instead installed under /usr/local/include and /usr/lib64
$ which netcdf
/usr/local/include/netcdf
$ which libnetcdf.so.11
/usr/lib64/libnetcdf.so.11
which leads to the error in model build.
I was trying to modify the makefile but it led to numerous other errors. So I kept the makefile unchanged, and built separate netcdf and pnetcdf from sources in separate local folders, and use the corresponding paths to rebuild PIO and to compile the model, which solved my problem. Note that these pnetcdf and netcdf paths should also be added into ~/.bashrc as LD_LIBRARY_PATH for MPAS model run. More instructions can be found here: http://www2.mmm.ucar.edu/projects/mpas/tutorial/UK2015/index.html.
Related
How can I link libxml on MinGW when using an omnetpp shell?
I am using omnetpp on a windows 10 machine.
My problem happens when I am trying to install the 3rd party package from here
I think that there is a problem in the Makefile failing to locate the libxml library
Following Rudi's answer (following the question) I changed the Makefile libxml path to I/mingw64/include/libxml2 but I still
get a undefined reference to 'xmlFunctionName' error (for many function names)
I tried to isolate the problem and to compile a sample of code from libxml2
Following the compilation guide: using gcc `xml2-config --cflags --libs` -o tree2 tree2.c
I got a fatal error: 'libxml/parser.h' file not found
When I replaced xml2-config --cflags --libs with -I/mingw64/include/libxml2
I got the same error as before undefined reference to 'xmlFunctionName'
what can I do to resolve that issue?
To this specific problem: libxml2 is actually already present as OMNET 5.x also uses it. All dependencies and tools are available in the tools/win64/mingw64 directory. The problem is that (for unknown reasons) the include file of the include/libxml2/libxml folder. The configure script correctly detects this and makes it available in the Makefile.inc as XML_CFLAGS= = -I/mingw64/include/libxml2
This must be added to the compiler flags for each file where you want to use the XML parser. (the library files are in the /mingw64/lib folder) so those are detected and can be used without additional config.
Generally, third party libraries should be available in the /mingw64/include and /mingw64/lib folders. You can either copy them manually there or try to install it with the mingw package manager (however that will most likely ruin your omnet installation as mingw64 is not particularly consistent and it is a rolling release - i.e. this is highly not recommended).
I install ceres in ubuntu and use the all of the command line in http://ceres-solver.org/installation.html Linux part from
sudo apt-get install libgoogle-glog-dev
all the way to
make install
Seems I have installed ceres solver and it dependency without problem.
But when I try to run the test file
bin/simple_bundle_adjuster ../ceres-solver-1.12.0/data/problem-16-22106-pre.txt
It shows
unable to open file ../ceres-solver-1.9.0/data/problem-16-22106-pre.tx
Then I try to compile helloworld in tutorial use command
g++ -I/usr/include/eigen3 helloworld.cpp -o helloworld
It gives me a bunch of problems.
undefined reference to google::InitGoogleLogging(char const*)'
helloworld.cpp:(.text+0x104): undefined reference toceres::Problem::Problem()'
helloworld.cpp:(.text+0x155): undefined reference to `ceres::Problem::AddResidualBlock(ceres::CostFunction*, ceres::LossFunction*, double*)'
I didn't list them all. But seems it cannot find things about google at all.
Hope you can help me!!
it gives me a mountain of problems.
Sounds like you're not linking to the library; this would cause references to be undefined. If you are calling the linker (G++ can be the linker), then add -lglog add the end, it should then link it to glog.
Similarly, you should also link to ceres.
Here's a snippet from the things I need to link to use a library which uses Ceres. In CMake. I suggest you start at the bottom/end and add things to the top to fix, you may need to prefix with -l to indicate that you need to link them.
I recommend using cmake, so that you can simply paste this list in a target_link_libraries(myexecutable listhere) and remove unnecessary/unused libraries;
umfpack
cxsparse
stlplus
glog
gomp
ccolamd
btf
klu
cholmod
lapack
blas
camd
amd
pthread
ceres
I have some fortran programs that would not compile in old versions of gfortran. I have to run multiple instances of this program and am using another system (a cluster system) which has centos5_x64 with gcc-4.1 !!
Therefore I had to build new version of gcc; I built both gcc-4.8.3 and gcc-4.9.2 in my home folder. These programs use hdf5 and so the latter also has to be compiled using the same compiler. I tested the fortran programs after removing the hdf5 dependency on both gfortran-4.8.3 and 4.8.9 and they get built and execute properly. I also tested simple C/C++ programs (with basic i/o and arithmetic) with the new gcc/g++(s); they work fine. Before compiling hdf5 libraries I set these environment variables:
PATH=<GCCPATH>:$PATH
LD_LIBRARY_PATH=<GCCLIB>
LD_RUN_PATH=<GCCLIB>
export PATH
export LD_LIBRARY_PATH
export LD_RUN_PATH
HDF5 specific instructions
4.3.7. Specifying other libraries and headers
Configure searches the standard places (those places known by the
systems compiler) for include files and header files. However,
additional directories can be specified by using the CPPFLAGS
and/or LDFLAGS variables:
$ CPPFLAGS=-I/home/robb/include \
LDFLAGS=-L/home/robb/lib \
LDFLAGS=-L<GCCLIB>
CPPFLAGS=-I<GCCINCLUDE>
then configured as:
./configure --prefix=$HOME/HDF5 --enable-fortran
During make I get this error:
/usr/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
This happens with both versions of gcc but not with the versions installed in the standard location (This happened in another system too which had gcc 4.4 installed). With general searching I got to know that this error is associated with the absence of a main() and in such cases -c flag has to be passed. However all examples of this error were from people's personal scripts and were not for libraries. Please let me know if I am missing something.
Upgrading the system OS is not a choice as of now.
As indicated in the comment by doqtor, I modified the Makefile post configure. It seems that CPPFLAGS and LDFLAGS were not set.
After setting the right CPPFLAGS and LDFLAGS in the Makefile, the compilation happened successfully.
I am currently working on a simple data synchonizer in a mixture of Fortran and C/C++ by using OpenMPI libraries. The synchonizer compiles and links correctly, as far as I can see:
f95 -o fortran_mpi_test *.o -L/usr/lib/gcc/x86_64-redhat-linux/4.1.1/
-L/usr/lib64/openmpi/1.4-gcc/lib/ -lmpi -lmpi_cxx -lstdc++
But when I execute the resulting executable on the same machined I get an error stating that one of the shared libraries is not found. That is confirmed by ldd.
Nevertheless the missing library libmpi_cxx.so.0 is located in one of the specified folders.
Could anyone give me a hint what I could have done wrong?
Check your environment variables. If your LIBRARY_PATH, LD_LIBRARY_PATH or similar vars have gotten out of sync or set to silly values you might not be searching the same directories for static libraries as you do for dynamics.
Also check out the ld.so manpage
I'm extremely new to using Makefiles and autoconf. I'm using the Camellia image library and trying to statically link my code against their libraries. When I run "make" on the Camellia image library, I get libCamellia.a, .so, .la, and .so.0.0.0 files inside my /usr/local/lib directory. This is the command I use to compile my code with their libraries:
gcc -L/usr/local/lib -lCamellia -o myprogram myprogram.c
This works fine, but when I try to statically link, this is what I get:
gcc -static -L/usr/local/lib -lCamellia -o myprogram myprogram.c
/tmp/cck0pw70.o: In function `main':
myprogram.c:(.text+0x23): undefined reference to `camLoadPGM'
myprogram.c:(.text+0x55): undefined reference to `camAllocateImage'
myprogram.c:(.text+0x97): undefined reference to `camZoom2x'
myprogram.c:(.text+0x104): undefined reference to `camSavePGM'
collect2: ld returned 1 exit status
I want to statically link because I'm trying to modify the Camellia source code and I want to compare my version against theirs. So after some googling, I tried adding AM_DISABLE_SHARED into the configure.in file. But after running ./configure, I still get the exact same Makefile. After I "make install", I still get the same results above.
What is an easy way to get two versions of my code, one with the original Camellia source code compiled and one with my modified version? I think static libraries should work. There is an easy way to get static libraries working or are there other simple solutions to my problem? I just don't want to re-"make" and re-"make install" everytime I want to compare my version against the original.
Did you re-run autoconf after adding AM_DISABLE_SHARED and before configure, make, make install? You also can just use configure --disable-dynamic to stop it building the shared libraries. Make sure you delete any previously installed ones - make uninstall should do that. I can't see anything else obviously wrong. Try being explicit:
gcc -static -o myprogram myprogram.c /usr/local/lib/libCamellia.a
or break it down into two steps and check the symbols in myprogram.o are what you expect with nm myprogram.o.
I am not skillful with autoconf and I don't know why your attempt to link statically fails, but if linking dynamically works I think using shared libraries would actually solve your problem a little better.
Just make two shared libraries, one with the original Camellia code and one with your modified version. Put them in two different directories, and when you run myprogram you can choose between them either by switching LD_LIBRARY_PATH (or whatever you're using to find libraries) or by keeping a symbolic link in /usr/local/lib and switching it between libraries. The advantage of this over static libraries (apart from the fact that this works) is that you can tinker with your modified code, rebuild the shared library and run without having to rebuild myprogram (as long as you don't modify the signatures).
P.S. An experiment: try removing the shared libraries from /usr/local/lib and rebuilding without the -static flag, just as if you were using the shared libraries. In theory this should cause gcc to use the static libraries instead. The results may give a clue to why the static link is failing.