Checking UnRAR version matches header and library - ignores LIBS variable

[hasse69]

What steps will reproduce the problem?

• run configure with LIBS='-lstdc++ -lpthread'

What is the expected output? What do you see instead?

Expected :
checking for matching UnRAR library and source version... yes

Actual:
checking for matching UnRAR library and source version... no
configure: error: in /dev/shm/rar2fs/rar2fs-1.8.4-test': configure: error: The version of UnRAR source pointed to by --with-unrar=../unrar and the current shared library picked up at link time are incompatible. Add an alternative library search path using --with-unrar-lib and/or an alternative source search path using --with-unrar and rerun configure. Seeconfig.log' for more details

What version of the product are you using? On what operating system?

• rar2fs r411. openSUSE 13.1 RC1.

Please provide any additional information below.

• When I tried to use static libunrar, this error occur. It needs LIBS variable for successfully compile. With shared version of libunrar, it doesn't needed. But, I think it should respect LIBS variable as other parts of checking some features.

I'll attach one patch can fix this.

Original issue reported on code.google.com by jyhpsycho on 2013-11-10

[hasse69]

Ok, but I do not think it is that simple. Actually, I do not really understand why setting
LIBS='-lstdc++ -lpthread' before calling configure should make the test fail? At least
I can not reproduce it. But I agree that user defined values should be taken into consideration
for many tests. Also, the precedence need to be considered. For LIBS it is not really
an issue, but eg. LDFLAGS should be checked before default/configured paths.

Original issue reported on code.google.com by hans.beckerus on 2013-11-10 11:54:07

[hasse69]

Can you please provide your config.log. I would really like to see why setting LIBS='-lstdc++
-lpthread' cause the test to fail on your system.

Original issue reported on code.google.com by hans.beckerus on 2013-11-10 11:56:48

[hasse69]

There were more to this than I expected. I actually tried to build a static variant
of rar2fs and stumbled into problems immediately. You should never use LIBS="-static".
That is completely wrong and could result is out-of-order linking. To build a static
variant of rar2fs, set LDFLAGS="-static" instead. That is more appropriate. I have
tried to address the problem of building a static binary in the attached configure.ac.
Could you please verify if it will resolve the issues you are having?

Original issue reported on code.google.com by hans.beckerus on 2013-11-10 18:39:08

---

- _Attachment: [configure.ac](https://storage.googleapis.com/google-code-attachments/rar2fs/issue-20/comment-3/configure.ac)_

[hasse69]

Hmm... I don't use -static option in any way... I maked only libunrar.a and delete libunrar.so
maked by default, and use it compiling rar2fs. It removes dependancy on libunrar.so.
I can provide all instructions what I do, but not now... :-(

I'll report all what I doing and results of your request 12 hours later.

Original issue reported on code.google.com by jyhpsycho on 2013-11-11 00:15:39

[hasse69]

No, the -static option is only applicable if you wish to compile the entire binary as
static. If you only wish to link towards a static variant of libunrar (.a) then that
should be possible too. I will report the need for a static variant build of libunrar
upstream. Could come handy to have native support for it in the makefile. 

Original issue reported on code.google.com by hans.beckerus on 2013-11-11 08:16:56

[hasse69]

Just tried it myself. With attached version of configure.ac it is possible to configure/build
towards a statically linked libunrar.a without having to specify anything in LIBS.
Please verify on your end too.

Original issue reported on code.google.com by hans.beckerus on 2013-11-11 08:46:16

[hasse69]

Yes, attached version of configure.ac works. it doesn't requires setting LIBS variable
even use static libunrar.

I just need remove dependancy on libunrar.so as I said before, not full static link.
Thus, I'm not use -static option. You're right that I should use -static option if
I requires full static-link to use under some specific environment.

I'll attach config.log files with current r411, regardless your new configure.ac works.

Original issue reported on code.google.com by jyhpsycho on 2013-11-11 11:07:45

---

- _Attachment: [r411-noLIBS-config.log](https://storage.googleapis.com/google-code-attachments/rar2fs/issue-20/comment-7/r411-noLIBS-config.log)_ - _Attachment: [r411-LIBS-config.log](https://storage.googleapis.com/google-code-attachments/rar2fs/issue-20/comment-7/r411-LIBS-config.log)_

[hasse69]

Thanks for verifying the fix. Committed to trunk.

Case closed.

Original issue reported on code.google.com by hans.beckerus on 2013-11-11 11:30:08