ViennaRNA / RNAz

RNAz - predicting structural noncoding RNAs
http://www.tbi.univie.ac.at/software/RNAz/
Other
15 stars 5 forks source link

[2.1] build issues #8

Closed wookietreiber closed 5 years ago

wookietreiber commented 9 years ago

I recently tried to build rnaz/2.1 on an up-to-date Arch Linux using gcc 5.1.0 and I get a lot of warnings like this one for both HairpinE and LoopEnergy:

fold.c:873:13: warning: ‘P’ is static but used in inline function ‘LoopEnergy’ which is not static
    energy = P->int21[type][type_2][si1][sq1][sj1];                                               

Also, linking fails, though this is maybe related to the abovementioned warnings:

g++ -o RNAz RNAz.o rnaz_utils.o svm_helper.o zscore.o cmdline.o strand.o svm.o -L../librna -lRNA -lm 
../librna/libRNA.a(alifold.o): In function `alifold':
/tmp/makepkg/rnaz/src/RNAz-2.1/librna/alifold.c:186: undefined reference to `HairpinE'
/tmp/makepkg/rnaz/src/RNAz-2.1/librna/alifold.c:203: undefined reference to `LoopEnergy'
/tmp/makepkg/rnaz/src/RNAz-2.1/librna/alifold.c:465: undefined reference to `HairpinE'
/tmp/makepkg/rnaz/src/RNAz-2.1/librna/alifold.c:479: undefined reference to `LoopEnergy'
collect2: error: ld returned 1 exit status
Makefile:242: recipe for target 'RNAz' failed
make[2]: *** [RNAz] Error 1
wookietreiber commented 9 years ago

Note, at a machine that runs on CentOS 6 with gcc 4.9.2 the compilation shows neither these warnings nor fails at linking.

skiwithuge commented 8 years ago

hi, did you resolve the problem? I've tried into two different machines with gcc v 5.3 (linux mint 17.3) and another one with gcc v4.4 (CentOS release 6.8) but I have the same error

wookietreiber commented 8 years ago

Well, there is a very simple solution, and that is to compile with an explicit, older C standard, like -std=gnu89. You can apply this solution by setting CFLAGS when running configure, e.g.:

./configure CFLAGS="-std=gnu89 -g -O2" --prefix=/usr

Note: I also added the -g -O2 flags because those are the standard ones that would otherwise be overwritten when supplying CFLAGS like that


However, this just avoids the issue by not talking about it - there is a reason why this was addressed by later C standards. I would not accept this as a solution to this issue. I would rather patch rnaz to comply to newer C standards.

rookie321 commented 7 years ago

I am still getting the same error even after configuring using ./configure CFLAGS="-std=gnu89 -g -O2" --prefix=/usr Anything that I am missing?

RaumZeit commented 5 years ago

These issues should have been resolved with version 2.1.1