I don't usually use Fedora or RPMs, so I'm flying blind here. There are lots of similar questions around here, but none that I found are to the exact point where I'm stuck.
I have the source RPM for an old game program on Fedora ("six" is the game). I want to add a couple of features, but first I want to make sure I know how to compile it so that any future problems are new. I have not made any changes yet at all.
I'm not completely helpless -- when I did
rpmbuild --recompile six-*.src.rpm
I got a complaint about a missing dependency: "kdelibs3-devel", but
dnf install kdelibs3-devel
took care of that.
However, now the complaints are more nuanced. When I retried rpmbuild, it ended with
checking crt_externs.h usability... no
checking crt_externs.h presence... no
checking for crt_externs.h... no
checking for _NSGetEnviron... no
checking for vsnprintf... yes
checking for snprintf... yes
checking for X... libraries /usr/lib64, headers .
checking for IceConnectionNumber in -lICE... yes
checking for libXext... yes
checking for pthread_create in -lpthread... yes
checking for extra includes... no
checking for extra libs... no
checking for libz... -lz
checking for libpng... -lpng -lz -lm
checking for libjpeg6b... no
checking for libjpeg... no
configure: WARNING: libjpeg not found. disable JPEG support.
checking for perl... /usr/bin/perl
checking for Qt... configure: error: Qt (>= Qt 3.3 and < 4.0) (library qt-mt) not found. Please check your installation!
For more details about this problem, look at the end of config.log.
Make sure that you have compiled Qt with thread support!
error: Bad exit status from /var/tmp/rpm-tmp.y8dvN5 (%build)
RPM build errors:
user mockbuild does not exist - using root
user mockbuild does not exist - using root
user mockbuild does not exist - using root
user mockbuild does not exist - using root
Bad exit status from /var/tmp/rpm-tmp.y8dvN5 (%build)
Several things here seem odd, but the obvious biggie is the failure to find Qt between 3.3 and 4.0. This obviously compiled for the Fedora maintainers, so the right thing should be available, but I have no idea what its exact name would be, or how to find it and make it available.
Help, please.
.
The best thing to do here is use higher-level tools. Specifically, use mock. This is a tool which:
manages a build environment (either a chroot or container-based),
so you don't have to worry about that,
handles things like the build dependencies, so you don't have to worry about that, and
makes sure that your build is "clean" rather than influenced by your own user environment so you don't have to worry about that.
In short: mock --rebuild six-*.src.rpm
If you see errors about a specific library missing, you can use dnf itself to find out the name. For example, on Fedora 35:
$ sudo dnf repoquery --whatprovides '*qt-mt*'
qt3-0:3.3.8b-88.fc35.i686
qt3-0:3.3.8b-88.fc35.x86_64
qt3-devel-0:3.3.8b-88.fc35.i686
qt3-devel-0:3.3.8b-88.fc35.x86_64
I guess you just need to dnf install qt3-devel.
As for libjpeg, do you have libjpeg-turbo-devel installed? Configure programs generally look for the -devel stuff rather than just the library (libjpeg). If you have it installed and it's still not picked up, maybe the software is just not compatible with libjpeg-turbo. Fixing that would be a separate challenge.
Using mock got me the ability to build the package, but I could not figure out how to do further work on it because the chroot left behind by mock did not seem functional. So I asked this question in a different way here, and got a really good answer (the second one).
Related
This is my first time using bedr. Upon loading the library all of the binary availbility checks fail.
library("bedr", lib.loc="~/R/R-3.4.4/library")
#
bedr v1.0.4
#
checking binary availability...
Checking path for bedtools... FAIL
Checking path for bedops... FAIL
Checking path for tabix... FAIL
tests and examples will be skipped on R CMD check if binaries are missing
I was originally using R-3.5 and I read somewhere that there are some bugs with R-3.5 that will cause this so I reverted to R-3.4.4. This didn’t seem to help. Additionally, I am using a company laptop at a new employer and am waiting on gaining adminstrative access to install/download programs as needed. I understand these issues might further complicate the matter. Does anyone have a way to diagnose the true cause of this failure and/or fix the problem?
You can install packages bedtools, bedops and tabix.
If you are in Unix environment just use sudo apt install to install these packages
After that all the checks should be PASS
I'm trying to set up pocl-0.11 on an ARM (llvm-3.3). I used ./configure --enable-debug --disable-icd --enable-testsuites=all (I'd like to get pocl to run without ICD loader as a first step).
During configure I got a couple of warnings about disabled tests due to missing glut, libDSL, boostlib, etc. Since the warnings 'only' concern some testsuites, I assume the configure is fine and I guess some basic tests will still be enabled!?
Furthermore I get the output:
checking LLC host CPU... cortex-a9
configure: using the ARM optimized kernel lib for the native device
<stdin>:1:19: error: 'test' declared as an array with a negative size
constant int test[sizeof(long)==8?1:-1]={1}; (Is that relevant? I don't really know what to do with this message.)
Eventually configure succeeds and make & make install run without any hint of a problem.
make check then fails all tests, even: check for pocl version FAILED (testsuite.at:29)
The 001/testsuite.log file indicates a linker problem!?
Do you have any idea?
Am I missing a configure flag or an environment variable? I didn't touch --prefix or any other paths.
LLVM 3.3 is quite old and its support will be dropped after the next pocl release. The configure error message you see probably means it fails to detect your CPU features correctly, but the testsuite error indicates that not all LLVM symbols are properly linked in. You can try fixing this by using a shared LLVM library, but I really suggest you to upgrade LLVM. The upcoming 3.7 should work now and has fixed several issues and includes better OpenCL C Clang support.
I would want to get the list of installed packages that depend on gcc (installed with homebrew). When I try:
brew uses --installed gcc
it gives no result. And if I check e.g. r's dependencies with brew deps r, it returns gcc (among others). So I assume brew uses should at least return the value r.
Did anyone encounter a similar problem and could shed some light on this?
This is not an authoritative answer, but it appears to me that this is because r depends on :fortran, which is some kind of virtual dependency that can be resolved in different ways. brew deps answers the question, what would I need to install before installing this formula. And in your case it decides that installing gcc is a way to satisfy the :fortran requirement. But the reverse is apparently not supported: It doesn't know just from looking at gcc that this can be used to resolve the virtual dependency :fortran. This is somewhat plausible if one considers the way that virtual dependencies are implemented in Homebrew. Usually, it just looks around in the file system to see if a required binary is available (including ones supplied outside of Homebrew), but it doesn't establish a formula dependency link once it finds a candidate.
(In fact, this case might be even more complex. If you look at brew deps r --tree, you will see that the dependency is actually on :gcc, which is another level of virtual dependency.)
Although not directly related to your question, also note that deps by default is recursive but uses is not. So in order to get a symmetric picture, you'd need to use deps -1 or uses --recursive.
I have an R package which is easily sped up by using OpenMP. If your compiler supports it then you get the win, if it doesn't then the pragmas are ignored and you get one core.
My problem is how to get the package build system to use the right compiler options and libraries. Currently I have:
PKG_CPPFLAGS=-fopenmp
PKG_LIBS=-fopenmp
hardcoded into src/Makevars on my machine, and this builds it with OpenMP support. But it produces a warning about non-standard compiler flags on check, and will probably fail hard on a machine with no openMP capabilities.
The solution seems to be to use configure and autoconf. There's some information around here:
http://cran.r-project.org/doc/manuals/R-exts.html#Using-Makevars
including a complex example to compile in odbc functionality. But I can't see how to begin tweaking that to check for openmp and libgomp.
None of the R packages I've looked at that talk about using openMP seem to have this set up either.
So does anyone have a walkthrough for setting up an R package with OpenMP?
[EDIT]
I may have cracked this now. I have a configure.ac script and a Makevars.in with #FOO# substitutions for the compiler options. But now I'm not sure of the workflow. Is it:
Run "autoconf configure.in > configure; chmod 755 configure" if I change the configure.in file.
Do a package build.
On package install, the system runs ./configure for me and creates Makevars from Makevars.in
But just to be clear, "autoconf configure.in > configure" doesn't run on package install - its purely a developer process to create the configure script that is distributed - amirite?
Methinks you have the library option wrong, please try
## -- compiling for OpenMP
PKG_CXXFLAGS=-fopenmp
##
## -- linking for OpenMP
PKG_LIBS= -fopenmp -lgomp
In other words, -lgomp gets you the OpenMP library linked. And I presume you know that this library is not part of the popular Rtools kit for Windows. On a modern Linux you should be fine.
In an unrelease testpackage I have here I also add the following to PKG_LIBS, but that is mostly due to my use of Rcpp:
$(shell $(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()") \
$(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
Lastly, I think the autoconf business is not really needed unless you feel you need to test for OpenMP via configure.
Edit: SpacedMan is correct. Per the beginning of the libgomp-4.4 manual:
1 Enabling OpenMP
To activate the OpenMP extensions for
C/C++ and Fortran, the compile-time
flag `-fopenmp' must be specified.
This enables the OpenMP directive
[...] The flag also
arranges for automatic linking of the
OpenMP runtime library.
So I stand corrected. Seems that it doesn't hurt to manually add what would get added anyway, just for clarity...
Just addressing your question regarding the usage of autoconf--no, you do not want to run autoconf with any arguments, nor should you redirect its output. You are correct that running autoconf to build the configure script is something that the package maintainer does, and the resulting configure script is distributed. Normally, to generate the configure script from configure.ac (older packages use the name configure.in, but that name has been discouraged for several years), the developer simply runs autoconf with no arguments. Before running autoconf, it is necessary to run aclocal, autoheader, libtoolize, etc... There is also a tool (autoreconf) which simplifies the process and invokes all the required programs in the correct order. It is now more typical to run autoreconf instead of autoconf.
The readline library allows the CLI for sqlite to accept arrow keys to recall previously typed commands. I can build without this and sqlite works, it's just a hassle not having this nice capability. I've installed readline-devel from yum and /usr/lib64/libreadline.so.5 is present as well as it's header files. When I run ./configure to build sqlite, I see these lines:
checking for library containing readline... no
checking for readline... no
The library path is set to the correct path:
LD_LIBRARY_PATH="/usr/lib64:/usr/local/lib:/lib:/usr/lib"
By default, ./configure does try to include readline support so there are no special "--with-XXXX" options needed.
Anyone every seen this problem? I need to use this newer version to get latest foreign key support. It's hassle running on CentOS as is bundles pretty old versions of apps but we don't have a choice right now and I cannot find an updated RPM with newer version of sqlite.
=== UPDATE ===
Ok, I found a solution but I don't completely like it...
First, I tried with this option:
./configure CPPFLAGS="-I/usr/include/ -DHAVE_READLINE"
That causes the readline functionality to get compiled into shell.c which is what is needed for starters. But, the linking fails because it cannot find libreadline. The only 'kludgy' way I could figure out to get it to link was to manually edit the Makefile after running the above ./configure command. I changed this line:
LIBS = -ldl -lpthread
to this:
LIBS = -ldl -lpthread -lreadline -ltermcap
Then I ran "make clean all" and "make install" and the readline functionality works in the CLI.
I tried every way I could think of to pass in the extra libraries including exporting using LIBS, exporting using READLINE_LIBS, exporting using LDFLAGS, nothing would work. If you set LIBS to anything, like "export LIBS="-lreadline", it causes configure to fail. The --help on configure about using LIBS seems to contradict what happens when you actually set it to any value.
Anyway, this works so I can live with it - but I don't particularly like it! :(
==== THE RIGHT SOLUTION ====
Well, wouldn't you know it. Spend hours trying to figure it out, then stumble onto the right tip on Google. Just needed to install ncurses-devel first. So, to summarize all that is needed to built it 'unkludgily':
yum install ncurses ncurses-devel
yum install readline readline-devel
yum install libtermcap libtermcap-devel
./configure
make
make install
No special command line options or exports or Makefile edits needed! Readline support is automatically built in by default now.