Building R package krb5 from source - c

I'm trying to install the package krb5 from source available on rforge rforge.
To do so I use the following command within RStudio (1.0.136) with R (3.3.1) on Windows 7.
install.packages("krb5",,"http://rforge.net/",type="source")
Unfortunately this results in the following error:
* installing *source* package 'krb5' ...
** libs
*** arch - i386
c:/Rtools/mingw_32/bin/gcc -I"C:/PROGRA~1/R/R-33~1.1/include" -DNDEBUG -I"d:/Compiler/gcc-4.9.3/local330/include" -O3 -Wall -std=gnu99 -mtune=core2 -c k.c -o k.o
k.c:1:18: fatal error: krb5.h: No such file or directory
#include <krb5.h>
^
compilation terminated.
make: *** [k.o] Error 1
Warnung: Ausführung von Kommando 'make -f "Makevars" -f "C:/PROGRA~1/R/R-33~1.1/etc/i386/Makeconf" -f "C:/PROGRA~1/R/R-33~1.1/share/make/winshlib.mk" SHLIB="krb5.dll" OBJECTS="k.o"' ergab Status 2
ERROR: compilation failed for package 'krb5'
* removing 'C:/Users/Fabian Desktop/Documents/R/win-library/3.3/krb5'
Warning in install.packages :
running command '"C:/PROGRA~1/R/R-33~1.1/bin/x64/R" CMD INSTALL -l "C:\Users\User\Documents\R\win-library\3.3" C:\Users\User\AppData\Local\Temp\RtmpCOnG2U/downloaded_packages/krb5_0.1.tar.gz' had status 1
Warning in install.packages :
installation of package ‘krb5’ had non-zero exit status
It seems as if the file "krb5.h" wasn't found. This makes sense since the package builds on MIT's Kerberos project available here.
The problem I am facing is that I've never built a C-project. Therefore I do not know how to "combine" the two projects or where to add the MIT-project to the R package such that it is available for the R package when building it. A short step by step guide I should take to make this working is much appreciated.

Caveat: I know nothing about the specifics of package krb5. But read on ...
A common pattern with Rcpp package is that they are interfaces between R on the one hand, and an external library on the other hand.
In order to compile code that connects two such worlds, you need header files and libraries from both. R covers its own side.
But krb5 likely only gives you the ability to talk Kerboros backends provided you have Kerberos (development) software installed. In other words krb5 is likely a gateway Kerberos, not Kerberos itself.

Related

"fatal error: bits/libc-header-start.h: No such file or directory" while compiling HTK

I'm getting the following issue when trying to run make on the HTK library:
(cd HTKLib && make HTKLib.a) \
|| case "" in *k*) fail=yes;; *) exit 1;; esac;
make[1]: Entering directory '/home/william/speech/htk/HTK-3.4.1/htk/HTKLib'
gcc -m32 -ansi -D_SVID_SOURCE -DOSS_AUDIO -D'ARCH="x86_64"' -Wall -Wno-switch -g -O2 -I. -DPHNALG -c -o HGraf.o HGraf.c
In file included from HShell.h:40:0,
from HGraf.c:54:
/usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such file or directory
#include <bits/libc-header-start.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
<builtin>: recipe for target 'HGraf.o' failed
make[1]: *** [HGraf.o] Error 1
make[1]: Leaving directory '/home/william/speech/htk/HTK-3.4.1/htk/HTKLib'
Makefile:96: recipe for target 'HTKLib/HTKLib.a' failed
make: *** [HTKLib/HTKLib.a] Error 1
I'm unsure what to do about this error. The libc-header-start.h file is present on my system:
$ find /usr -name libc-header-start.h
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h
Running gcc -H -fsyntax-only /usr/include/stdio.h appropriately returns
. /usr/include/x86_64-linux-gnu/bits/libc-header-start.h
.. /usr/include/features.h
... /usr/include/x86_64-linux-gnu/sys/cdefs.h
etc.
Also, compiling and running a sanity-check C file works fine (simply executing printf("hello!"); in its main method).
Apologies if this is a well-known error - my experience with C libraries stops at compiling and installing them using make.
UPDATE
Per the accepted answer below I executed sudo apt-get install gcc-multilib to install the missing 32 bit libraries.
Afterwards I got an error with a similar cause: "/usr/bin/ld: cannot find -lX11" error when installing htk. I resolved this by executing sudo apt-get install libx11-dev:i386 libx11-dev to retrieve the missing 32 bit library.
The -m32 is telling gcc to compile for a 32-bit platform. On a 64-bit machine, gcc normally only comes with 64-bit libraries. You have two options:
Install 32-bit headers and libraries. Here's how you'd do this on Ubuntu.
Run this command:
sudo apt-get install gcc-multilib
Compile for 64-bit instead. Modify this line in the file named configure:
CFLAGS="-m32 -ansi -D_SVID_SOURCE -DOSS_AUDIO -D'ARCH=\"$host_cpu\"' $CFLAGS"
Delete -m32, giving you:
CFLAGS="-ansi -D_SVID_SOURCE -DOSS_AUDIO -D'ARCH=\"$host_cpu\"' $CFLAGS"
Run ./configure, then make clean, then make
However, I would recommend against this approach. The library authors went out of their way to make this build for 32 bits on a 64 bit system, and I can't guarantee that it will work correctly if you do this. (It does compile, though.)
Below is one way to debug and fix this issue. Since most linux installations differ in one way or another, YMMV.
Find which package installed libc-header-start.h.
$ dpkg -S libc-header-start.h
libc6-dev:amd64: /usr/include/x86_64-linux-gnu/bits/libc-header-start.h
On a working system, /usr/include/bits is a symlink to /usr/include/x86_64-linux-gnu/bits. Running dpkg search gives us:
$ dpkg -S /usr/include/bits
libc6-dev-i386: /usr/include/bits
Installing libc6-dev-i386 creates the symlink and the error is addressed.
However, subsequently I ran into a linker error with the linker not being able to find libgcc (-lgcc). Apparently Linux default linker needs libgcc in most cases. Further debugging the issue with linker verbosity enabled lead me to missing lib32gcc-10-dev package.
In short, unless a very controlled build environment is desired, just install gcc-multilib package when using -m32 (needed for gcc or clang). For C++, g++-multilib is also required.

Recipe for target 'graphite-clast-to-gimple.o' failed when I compile GCC Cross-Compiler

I would like to create a GCC cross-compiler and I follow the instruction here here But the problem is each time when I make gcc will have same error blow.
../../gcc-4.8.2/gcc/graphite-clast-to-gimple.c:897:24: error: ‘isl_lp_ok’
was not declared in this scope
assert (lp_result == isl_lp_ok);
^
../../gcc-4.8.2/gcc/graphite-clast-to-gimple.c:898:34: error:
‘isl_int_get_gmp’ was not declared in this scope
isl_int_get_gmp (isl_value, low); ^
../../gcc-4.8.2/gcc/graphite-clast-to-gimple.c:900:57: error: ‘isl_set_max’
was not declared in this scope
lp_result = isl_set_max (domain, dimension, &isl_value);
^
../../gcc-4.8.2/gcc/graphite-clast-to-gimple.c:904:27: error:
‘isl_int_clear’ was not declared in this scope
isl_int_clear (isl_value); ^
Makefile:1058: recipe for target 'graphite-clast-to-gimple.o' failed
make[1]: *** [graphite-clast-to-gimple.o] Error 1
make[1]: Leaving directory '/home/mike/src/build-gcc/gcc'
Makefile:3927: recipe for target 'all-gcc' failed
make: *** [all-gcc] Error 2
At first,I think it may caused by the version problem because the gcc on my openSUSE is 4.8.3,but nothing changed after I use version 4.8.2.
Thanks a lot!
There's a problem with the latest version (0.14?) of the ISL library - the API is not compatible with gcc as of 4.9.2. As for building CLooG, the ISL-0.12.1 version included with 0.18.2 doesn't get configured properly. So you need to build and install your own libraries, and then use those when configuring gcc.
1/. isl-0.12.2
> ./configure --prefix=$CROSSDIR --with-gmp-prefix=$GMPDIR
> make install # and rehash, etc.
where CROSSDIR is where you're installing your cross compiler toolchain, and GMPDIR is the root directory containing lib and include directories for GMP. Unfortunately, this means you will need to build GMP, MPFR, and MPC separately and install, or install them from a package system first. But you might not need this (see below).
2/. cloog-0.18.2
> ./configure --prefix=$CROSSDIR --with-isl-prefix=$CROSSDIR \
--with-gmp-prefix=$GMPDIR
There's a ridiculous issue where the Makefile has 'cmake' strings lying about. The solution (from clfs.org) :
> sed '/cmake/d' Makefile > Makefile.new
> mv Makefile.new Makefile
> make install # and rehash, etc.
When configuring gcc, use: --with-isl=$CROSSDIR --with-cloog=$CROSSDIR, and you will need options for: --with-gmp, --with-mpfr, --with-mpc
Alternatively - following the instructions you're using, it may be sufficient to move isl-0.12.2 & cloog-0.18.2 to the isl and cloog subtrees in the gcc source tree. After the configure, go into the cloog build subdirectory and edit the Makefile as above. I haven't tried this. I build and install the packages separately under CROSSDIR for other reasons.
If you are on Linux, you could probably get the development packages for your system. I know the commands for a Debian-based system such as Ubuntu and its variants.
sudo apt-get install libisl-dev
sudo apt-get install libcloog-isl-dev
After that, delete the isl and cloog directories in your gcc folder, then try to continue from:
make all-gcc
If you don't have a Debian-based system, some hunting around in Google Forest should help.

compiling Vim 7.4 under AIX 6.1

I have a problem while compiling Vim 7.4 under AIX 6.1.
My options for the configure script are: "--prefix /opt/freeware/bin" and "--enable-pythoninterp".
There where no Errors while running the configure Script but when I try to run "make" I get the error message:
cd src && make first
cc -qlanglvl=extc89 -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_ATHENA -DFUNCPROTO=15 -g -o objects/regexp.o regexp.c "regexp_nfa.c"
line 4410.1: 1506-046 (S) Syntax error.
make: 1254-004 > The error code from the last command is
1.
Stop. make: 1254-004 The error code from the last command is 2.
Stop.
Does anyone know what to do?
I had compiled Vim 7.4 in my home directory so I know that there is a workaround but I can't find it anymore.
AIX's built in make (based on standard AT&T make) is not compatible with the Makefiles built by autoconf tools. Use GNU make (gmake) instead. You may already have it installed (check /opt/freeware/bin), install from the Linux Toolbox for AIX set (from IBM), or from one of the websites providing prebuilt GNU tools for AIX systems (perzl, bullfreeware, etc). Just provide an alias from make to gmake, or override the use of make in the Makefile itself.

Default compiler Macports

Not sure if this is the correct place for this kind of question. If not, please point me in the right direction.
I'm using OSX 10.5.8 on a white 13" macbook with Xcode 3.1.4. When installing py27-bottleneck through macports, I get the following error
---> Building py27-bottleneck
running build
running build_py
package init file 'bottleneck/tests/__init__.py' not found (or not a regular file)
package init file 'bottleneck/src/func/__init__.py' not found (or not a regular file)
package init file 'bottleneck/src/move/__init__.py' not found (or not a regular file)
package init file 'bottleneck/tests/__init__.py' not found (or not a regular file)
package init file 'bottleneck/src/func/__init__.py' not found (or not a regular file)
package init file 'bottleneck/src/move/__init__.py' not found (or not a regular file)
running build_ext
building 'func' extension
/usr/bin/gcc-4.2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -arch i386 -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c bottleneck/src/func/func.c -o build/temp.macosx-10.5-i386-2.7/bottleneck/src/func/func.o
In file included from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/ndarraytypes.h:1760,
from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/ndarrayobject.h:17,
from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/arrayobject.h:4,
from bottleneck/src/func/func.c:314:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/__ufunc_api.h:242: warning: ?_import_umath? defined but not used
cc1(53864) malloc: *** mmap(size=298745856) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
cc1: out of memory allocating 298742336 bytes after a total of 0 bytes
error: command '/usr/bin/gcc-4.2' failed with exit status 1
Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-bottleneck/py27-bottleneck/work/Bottleneck-0.8.0" && /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 setup.py --no-user-cfg build
Exit code: 1
Error: org.macports.build for port py27-bottleneck returned: command execution failed
Warning: targets not executed for py27-bottleneck: org.macports.activate org.macports.build org.macports.destroot org.macports.install
Please see the log file for port py27-bottleneck for details:
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-bottleneck/py27-bottleneck/main.log
Error: Problem while installing py27-bottleneck
I don't really know what the problem is and why this had happened, but what I noticed was that macports is still using an old compiler.
So does anybody know how I can fix this problem?
Also, why is macports still using gcc-4.2, while I have all my symlinks pointing at /opt/local/bin/gcc-mp-4.8. I remember having this problem earlier with installing some other python packages (or maybe it was this one, I don't remember), so I forced macports to use the newer compiler by changing the makefile and it worked temporarily. Until I started upgrading my outdated ports. Obviously now macports encountered linking errors and just reinstalled the all those packages (this is where I am now). So why does macports not just use the newer compiler? Or how can I make him do this? (maybe I shouldn't?)
Any help is appreciated. Thanks.
On 10.5.8 with Xcode 3.1.4 MacPorts uses the following compilers (in-order, unless blacklisted by ports because known to break):
GCC 4.2 from /usr/bin
A MacPorts build of the same compiler (with a few minor bugfixes)
GCC 4.0 from /usr/bin
Clang 3.3 from MacPorts
It seems this port should be blacklisting GCC 4.2 (and probably 2. and 3., too). You could file that as a bug, but to be honest, support for 10.5 is only given on a best-effort basis because most maintainers can't test on this platform anymore, so that's probably not getting you anywhere unless you provide a patch with your report.
You could override the compiler from command line like you did before. To stop rev-upgrade from immediately starting rebuilds, you can set revupgrade_mode report in your macports.conf. I'd have to see the output of port -dy rev-upgrade when it encounters broken ports to know why it produces broken binaries.
It has already been mentioned that the select mechanism doesn't affect which compilers MacPorts chooses for its ports (because depending on what's selected by the user would add another variable that might make builds unreproducible, which is something we're trying to avoid). MacPorts' default compilers can be changed, but doing so is completely unsupported and deliberately undocumented. That being said, if you still want to attempt this, https://apple.stackexchange.com/questions/118550/define-local-keyword-globally-in-a-macports-config/122997#122997 has some info on how to do that.

error installing BRugs "C compiler cannot create executables"

I am trying to install the R library BRugs on my Ubuntu 12.04 desktop.
> sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: x86_64-pc-linux-gnu (64-bit)
But I get the following error:
* installing *source* package ‘BRugs’ ...
** package ‘BRugs’ successfully unpacked and MD5 sums checked
checking for prefix by checking for OpenBUGS... /usr/bin/OpenBUGS
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/tmp/RtmpnNLTG1/R.INSTALL488b7635d4c0/BRugs':
configure: error: C compiler cannot create executables
See `config.log' for more details
ERROR: configuration failed for package ‘BRugs’
* removing ‘/home/myuser/lib/R/BRugs’
Warning in install.packages("BRugs") :
installation of package ‘BRugs’ had non-zero exit status
The downloaded source packages are in
‘/tmp/Rtmp2ytOWn/downloaded_packages’
Here is a link to config.log. It is difficult to tell what the error is, except that the errors starts with gcc: error: unrecognized option '-V'.
How can I get around this error (and install BRugs)?
According to the package description:
Versions running on Linux and on 64-bit R under Windows are in "beta"
status and less efficient.
And it looks like configure is trying to build the package using 32-bit executables (note the -m32 flags). It's probably best if you contact the package maintainer(s) and ask them how to build the 32-bit executable under 64-bit Ubuntu.

Resources