Linking preinstalled libraries from gfortran in Mac OSx 10.6 - linker

I have been trying to compile a certain code written in fortran90 and C, for a few days now. I am using gfortran and gcc. The code needs to link to lapack, blas and fftw3 libraries. I have all three installed in my macbook pro. But when I run the configure script, for some reason, it fails to locate the fftw3 libraries.
Here is my configure line:
./configure --prefix=`pwd` --with-fft=fftw3 \
--with-fft-lib='-I/opt/local/include -L/opt/local/lib -lfftw3 -lm' \
--with-blas='-I/opt/local -L/opt/local -lblas' \
--with-lapack='-I/opt/local -L/opt/local -llapack' \
FCFLAGS='-O3 -m64'
I have used exactly the same linking line for lapack, blas and as well as fftw3. Configure is able to find lapack and blas but fails to link fftw3. Does anyone have any idea what is happening here? I would appreciate any help.
Thanks,
kopinjol
Hi everyone,
First of all thanks Hristo Iliev for your answers earlier. I have been able to fix that problem with linking the libraries. You were right about using different compilers for the libraries and the main code. That was the problem. And when I compiled them with the same compiler, the linking problem went away. But now I have another issue.
In the code there is a function call like this:
call io_open(info_files(n_files)%unit,trim(dir)//"/info")
The io_open function is defined as follows:
subroutine io_open(unit, file, status, form)
integer, intent(out) :: unit
character(len=*), intent(in) :: file
character(len=*), intent(in), optional :: status, form
integer :: iostat
character(len=20) :: status_, form_
The error I get is this:
call io_open(info_files(n_files)%unit, trim(dir)
1
Error: Syntax error in argument list at (1)
Basically it seems that the code gives a syntax error in
trim(dir)//"/info"
which is the filename in the function call.
Now the code compiles without any problem on a linux box (I was using ubuntu, the most recent release). I get the error only on my macbook pro running osx 10.6 .
Also surprisingly, the code compiles when I define an extra variable fname as
fname=trim(dir)//"/info"
and then use it for the function call
call io_open(info_files(n_files)%unit,fname)
Now I can make the substitution in all the function calls in the code, which are quite a few and it will probably take me a few hours to make the change by hand. But it somehow doesn't make sense that the same code with the same compilers compile without error in linux but fails in the mac. Does anyone have any idea as to what may be going wrong? I will appreciate any input.
Thanks in advance,
kopinjol

Thanks for the reply Hristo Iliev. I just figured out the problem. The problem was that I was using different versions of the same compiler. Once I updated the environment variables with compilers of the same versions, it all started working.
This is what I did,
export FC="gfortran-mp-4.6 -m64"
export F77="gfortran-mp-4.6 -m64"
export F90="gfortran-mp-4.6 -m64"
export CC="gcc-mp-4.6 -m64"
export CXX="g++-mp-4.6 -m64"
export CPP="cpp-mp-4.6 -m64 -C -ansi"
export FCCPP="cpp-mp-4.6 -m64 -C -ansi"
export FCFLAGS="-O3"
export FFLAGS="-O3"
As explained in the APE mailing list.
Thanks again,
kopinjol

Related

Sqlite3 build through a vala cmake system

I've been trying to compile a vala application through a cmake build system, but have been running into problems when trying to link the sqlite3 package. When running make I get
CMakeFiles/app.dir/Database/Database.c.o: In function `template_database_construct_from_file':
Database.c:(.text+0x8a): undefined reference to `sqlite3_open'
Database.c:(.text+0xaa): undefined reference to `sqlite3_close'
Database.c:(.text+0x116): undefined reference to `sqlite3_errcode'
Database.c:(.text+0x131): undefined reference to `sqlite3_errmsg'
As well as a bunch of almost identical errors. I can test the code by compiling it through the command line using --pkg sqlite3 and it has compiled without any problems. So why is it not working properly when trying to compile from cmake?
Any help is greatly appreciated. Thank you!
You need to add results of pkg-config --libs sqlite3 to your LDFLAGS or something. Although I don't use CMake, I think this is a problem of your template. I experienced the same problems using Autotools.
I'd need to see your CMakeLists.txt to better understand your problem.
Still, to link a library to a CMake vala build, do this:
find_package(PkgConfig)
pkg_check_modules(SQLITE3 REQUIRED sqlite3)
set(CFLAGS
${SQLITE3_CFLAGS} ${SQLITE3_CFLAGS_OTHER}
... )
add_definitions(${CFLAGS})
set(LIBS
${SQLITE3_LIBRARIES}
... )
link_libraries(${LIBS})
set(LIB_PATHS
${SQLITE3_LIBRARY_DIRS}
... )
link_directories(${LIB_PATHS})
("..." stands for the rest of your dependencies)
More complete example is here: https://github.com/felipe-lavratti/vala-cmake-example

Portable Makevars for R package using C, GSL and OpenMP with help of Rcpp

I am constructing an R package where I have few third party C functions which use GSL and OpenMP, and I then call these from R using wrappers made with Rcpp (which just modify some arguments and call the appropriate C function). Everything works fine in my Windows machine, but I am not sure how to define the Makevars.win and Makevars file in a portable way. My Makevars.win looks like this:
## This assumes that the LIB_GSL variable points to working GSL libraries
PKG_CPPFLAGS=-I$(LIB_GSL)/include -I../inst/include
PKG_LIBS=-L$(LIB_GSL)/lib/x64 -lgsl -lgslcblas $(SHLIB_OPENMP_CFLAGS)
PKG_CFLAGS=$(SHLIB_OPENMP_CFLAGS)
It is basically copied from various sources. Like said, this compiles in my computer (using toolchain of from Rtools), and if I remove PKG_CFLAGS=$(SHLIB_OPENMP_CFLAGS) I can also compile without OpenMP (for some reason I don't understand I get error if I remove OpenMP flag in PKG_LIBS).
My Makevars file looks identical, but I don't have access to Unix platforms so I am not sure how to deal with that side. My guess is that I need to replace LIB_GSL with something?
EDIT:
Okay, I think I finally understand how configure etc. works and was able to get everything working.
My Makevars.win:
## This assumes that the LIB_GSL variable points to working GSL libraries
PKG_CPPFLAGS=-I$(LIB_GSL)/include -I../inst/include
PKG_LIBS="-L$(LIB_GSL)/lib/$(R_ARCH)" -lgsl -lgslcblas $(SHLIB_OPENMP_CFLAGS)
PKG_CFLAGS=$(SHLIB_OPENMP_CFLAGS)
My Makevars.in:
GSL_CFLAGS = #GSL_CFLAGS#
GSL_LIBS = #GSL_LIBS#
PKG_LIBS=$(GSL_LIBS) $(SHLIB_OPENMP_CFLAGS)
PKG_CFLAGS=$(GSL_CFLAGS) $(SHLIB_OPENMP_CFLAGS)
And my configure.ac:
AC_INIT([testpackage], 0.0.1)
## Use gsl-config to find arguments for compiler and linker flags
##
## Check for non-standard programs: gsl-config(1)
AC_PATH_PROG([GSL_CONFIG], [gsl-config])
## If gsl-config was found, let's use it
if test "${GSL_CONFIG}" != ""; then
# Use gsl-config for header and linker arguments
GSL_CFLAGS=`${GSL_CONFIG} --cflags`
GSL_LIBS=`${GSL_CONFIG} --libs`
else
AC_MSG_ERROR([gsl-config not found, is GSL installed?])
fi
# Now substitute these variables in src/Makevars.in to create src/Makevars
AC_SUBST(GSL_CFLAGS)
AC_SUBST(GSL_LIBS)
AC_OUTPUT(src/Makevars)
I then run autoconf in testpackage directory in order to get configure file, which in turn converts Makevars.in to Makevars when running R CMD INSTALL.
There are a few CRAN packages using the GSL, and/or our RcppGSL bindings. Here is what I do in one of these (my RcppZiggurat package):
PKG_CPPFLAGS = -I. -I../inst/include
## Use the R_HOME indirection to support installations of multiple R version
PKG_LIBS = `$(R_HOME)/bin/Rscript -e "RcppGSL:::LdFlags()"`
That is the entire /src/Makevars. You can trivially add the same OpenMP variable from R. This does of course create a dependency on RcppGSL (as I already use it in RcppZiggurat). Else you can look into the R/init.R of RcppGSL and see how it tries to talk to gsl-config and store those values. You can do the same in src/Makevars -- it is just basic Make usage and nothing Rcpp specific.

Ubuntu libdispatch

I am trying to port a program that uses GCD (Grand Central Dispatch) from OSX to Ubuntu 11.10. I installed libdispatch but I keep getting the following error:
undefined reference to dispatch_main()
The strange thing is that dispatch_main() is declared in a header file that I include and I call other functions declared in that header file and the compiler recognizes them. It is only dispatch_main() that it cannot see and if I call dispatch_main(2) it says that there are too many arguments, so I know the compiler can see the header.
I tried separating the compile and link steps (clang -c...) since that worked for an undefined reference error before, but it doesn't seem to do anything here...
Anybody have any suggestions? I'm pretty stumped on this one...
It sounds like you are missing the library from your link line. When you compile your program into an executable, add the library to the command. I am guessing it should look something like this:
clang x.c y.c z.c -ldispatch

Why am I getting the message "Single-stepping until exit . . . which has no line number information" in GDB?

I've compiled my C program using gcc 4.4.1 using the flag -g, but when I try to step through one of my functions in gdb version 7.0, I get the message:
"Single stepping until exit from function _DictionaryTree_getNodeList,
which has no line number information."
Can someone tell me why this is happening?
Just guessing, but is _DictionaryTree_getNodeList in another file that wasn't compiled with -g?
I had the same problem but in my case adding -g to the compiler wasn't enough so I used -ggdb as suggested by Manav.
In my case, the problem was version skew between gcc and gdb.
After landing here from search and none of these answers fit my situation, I figured out that (because of aliases / symlinks / Makefile / environment variables) I was accidentally using a newer GCC (4.8.x) and an older GDB (7.2). Stepping up to a newer version of GDB (7.8) fixed the problem. For some reason, using a newer GCC and older GDB didn't work.
I had this error message too but the source of my problem was different. If anyone is still having any problems, make sure you have #include <stdio.h> in your file, with the the appropriate brackets around stdio.h (the text message would not show up if I had it around stdio.h).
I had the same issue, when I compiled a file using -g option and without -g option.
For one of the file, the gdb showed line number without any issues(even when it was compiled without -g option)..
And for the other file, I had to explicitly mention -g flag...
Any ideas as to whether the source file could be loaded at run time in
GDB with cross referencing would be good solution... by mapping the
lines to the addresses :D.
I had this issue because I was debugging a shared library without pointing LD_LIBRARY_PATH to correct location with debug endstates.
you can use
export LD_LIBRARY_PATH=<location of the debug build of the .so file>:$LD_LIBRARY_PATH
Hopefully this is helpful to someone
I had the same trouble despite I was already compiling with -g2. Changing it to -g3 did the trick.
Im using GBD 12 , im not able to use any of these flags and options , also im debugging .exe file , so yes I used makefile

Errors while compiling Neko VM OS X

I'm trying to compile the Neko VM on Mac OS X (10.5.7) using GCC 4.01 and I'm completely stuck, because it stops while compiling saying:
vm/threads.c:202: error: conflicting types for 'neko_thread_register'
vm/neko_vm.h:37: error: previous declaration of 'neko_thread_register' was here
I've tried googling this and some say it's because of lack of a "prototype" and some say it's because of a header include being done several times, and I can't really find any of those.
The affected line in threads.c:202 looks like this:
EXTERN bool neko_thread_register( bool t ) {
And the affected line in neko_vm.h:37 looks like this:
EXTERN bool neko_thread_register( bool t );
I can't see any difference in them, besides one of them being the implementation of the other.
The compiler command I'm using is:
cc -Wall -O3 -v -fPIC -fomit-frame-pointer -I vm -D_GNU_SOURCE -arch i386 -L/usr/local/lib -L/opt/local/lib -I/opt/local/include -o vm/threads.o -c vm/threads.c
I'd appreciate some ideas on what i might be able to do here, I don't really know where to go from here.
A mirror of the code for Neko which I'm trying to compile can be found here.
Thanks!
Have you tried compiling that file alone and outputting the preprocessed version? It could be that the scope or linkage macros are being modified somewhere in between the header file and the implementation file-- the same could be true of the 'bool' type, which is usually a macro defined by a system header.
According to the GCC 4.2 docs here, you should need to add the -E flag to the compilation line above, and you ought to change -o vm/threads.o to -o vm/threads.i so a file with the correct extension is created (.i means 'preprocessed file', essentially).
First, make sure you compile this as C, not C++.
Second, without seeing the code, it's pretty much impossible to say what the problem is.
But reading the error messages is often helpful (even before you google them):
Apparently neko_thread_register is declared twice, once in threads.c:202 and once in neko_vm.h:37, and the two declarations have different (conflicting) types. So look at the two declarations. If you can't see a problem with them, show us some code.
At the very least, seeing those two lines of code would be necessary. Most likely, the types are typedefs or macros or something similar, and then we'd need to see where they are defined as well.
Without seeing the code, all we can do is repeat the compiler error. "neko_thread_register has two conflicting definitions, at the lines specified."
Did you uncomment this line:
# For OSX
#
# MACOSX = 1 <-- this one
In the makefile?

Resources