Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build failure due to zlib test in configure #4652

Closed
wesnm opened this issue Jul 28, 2020 · 3 comments · Fixed by #4662
Closed

build failure due to zlib test in configure #4652

wesnm opened this issue Jul 28, 2020 · 3 comments · Fixed by #4662
Milestone

Comments

@wesnm
Copy link

wesnm commented Jul 28, 2020

Building on FreeBSD fails due to an issue in configure created in #3974 when "pkg-config --libs zlib" only contains "-lz" and the expression is not guarded in some way, e.g., with "--" or prepending fixed text such as "x"

** using staged installation
expr: illegal option -- l
expr: usage: expr [-e] expression

expr: illegal option -- l
expr: usage: expr [-e] expression

@mattdowle
Copy link
Member

mattdowle commented Jul 28, 2020

Thanks.

So we're talking about these two lines in configure:

lib=`pkg-config --libs zlib`
expr "$lib" : ".*-lz$" >/dev/null

For me, pkg-config --libs zlib contains only -lz on my machine; i.e. it returns -lz only. Could you explain a little more please? Why doesn't that work on FreeBSB? What does pkg-config --libs zlib return for you?

@wesnm
Copy link
Author

wesnm commented Jul 28, 2020

There are some differences in the Linux expr and FreeBSD. From the FreeBSD man page:

Compatibility with previous implementations
Unless FreeBSD 4.x compatibility is enabled, this version of expr adheres
to the POSIX Utility Syntax Guidelines, which require that a leading
argument beginning with a minus sign be considered an option to the
program. The standard -- syntax may be used to prevent this
interpretation. However, many historic implementations of expr,

On my FreeBSD machine:

[morganw@mercury:~/tmp$]: pkg-config --libs zlib           
-lz
[morganw@mercury:~/tmp$]: expr `pkg-config --libs zlib` : '.*-lz$'
expr: illegal option -- l
expr: usage: expr [-e] expression

[morganw@mercury:~/tmp$]: expr -- `pkg-config --libs zlib`  : '.*-lz$'
3
[morganw@mercury:~/tmp$]: expr x`pkg-config --libs zlib` : '^x.*-lz$'
4

On a Linux machine:

[morganw@media:~$]: pkg-config --libs zlib
-lz
[morganw@media:~$]: expr `pkg-config --libs zlib` : '.*-lz$'
3
[morganw@media:~$]: expr -- `pkg-config --libs zlib` : '.*-lz$'
3
[morganw@media:~$]: expr x`pkg-config --libs zlib` : '^x.*-lz$'
4

The "failure" occurred in 1.12.8 as well, but the end result was a successful build because the src/Makevars file exists in the tree, whereas in 1.13.0 the failure to find zlib causes the configure script to exit before src/Makevars is generated from src/Makevars.in. Perhaps that unconditional exit needs to be reconsidered, given that the OpenMP tests follow it. I don't know how universal the "--" guard for expr is, so perhaps prepending with a string is more portable?

patch.txt

@mattdowle
Copy link
Member

mattdowle commented Jul 28, 2020

Thanks, Morgan! Helps a lot, especially the aspect of not creating Makevars which also occurs in #4640. The Makevars started to be generated in #3984.

What I had really wanted to do originally was pass the result of pkg-config --libs zlib (i.e. -lz) through to R CMD build somehow. But I didn't know how to do that. So I put the -lz in Makevars (fixed, hardcoded) and added output to configure to tell us if it ever isn't "-lz", or if zlib isn't available, so that users know what to install. But if we're generating Makevars now, then maybe we have a way to pass it through. That would avoid needing to test for "-lz" at all, we could echo the value.

Thanks again, I think I understand what's going on now.

@mattdowle mattdowle added this to the 1.13.1 milestone Jul 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants