exec_prefix used before expanded

[andhe]

Hello!

Trying to build this project (on Debian) but running into issues when enabling the python3 bindings (python2 disabled so far):

The configure.ac references $exec_prefix in relation to the python bindings. The configure file generated in my build puts the code expanded from configure.ac related to $exec_prefix before it puts the code to expand exec_prefix from $prefix if exec_prefix is left at its default NONE value. I thus end up with python bindings being installed in NONE/lib/python3.*/.... rather than /usr/lib/python3.*/....

root@mbpah:/build/libbytesize-0.9# cat -n configure | grep -A 2 -B 2 PYTHON3_EXECDIR=
 13641	  PYTHON3_EXEC_PREFIX='${exec_prefix}'
 13642	
 13643	      PYTHON3_EXECDIR=`$python3 -c "import distutils.sysconfig; \
 13644	                                print(distutils.sysconfig.get_python_lib(1,0,prefix='${exec_prefix}'))"`
 13645	      py3execdir=$PYTHON3_EXECDIR

root@mbpah:/build/libbytesize-0.9# cat -n configure | grep -A 2 -B 2 'test.*exec_prefix.*NONE.*prefix'
 13824	test "x$prefix" = xNONE && prefix=$ac_default_prefix
 13825	# Let make expand exec_prefix.
 13826	test "x$exec_prefix" = xNONE && exec_prefix='${prefix}'
 13827	
 13828	# Transform confdefs.h into DEFS.

root@mbpah:/build/libbytesize-0.9# 

I was told the solution was to move the usage of $exec_prefix from configure to make phase, but don't see how to do that here.

[andhe]

Working around this issue can be done by explicitly passing --exec-prefix=/usr to configure when building..... This gets the ${exec_prefix} variable expanded early enough.

[vpodzime]

On Fedora ${exec_prefix} (somehow) defaults to /usr/local. This is how configure looks on my system (F25) - https://paste.fedoraproject.org/paste/n~uAETFvsWAmJWBQXSwcNV5M1UNdIGYhyRLivL9gydE=

I have no idea how to work this around. But I guess other packages must have the same problem on Debian?

[andhe]

I don't think this really is distro-specific rather autotools version dependant.

As documented in autoconf docs1 exec_prefix defaults to $prefix and prefix defaults to /usr/local.
This can be seen in the second cat command in the original report above. That part is what I call "expanded" (because before these rows exec_prefix and prefix contains NONE if not explicitly set). The problem is that autotools/autoconf doesn't seem to know that your configure.ac snippet that uses ${exec_prefix} must be put after the "expansion" of prefix and exec_prefix. Neither of exec_prefix or prefix contains their "default" values until that time.

[andhe]

In other words, it seems kind of by luck that your generated configure file has the exec_prefix snippet from configure.ac after the "expansion", while I end up not being so lucky with it before expansion.

[vpodzime]

In other words, it seems kind of by luck that your generated configure file has the exec_prefix snippet from configure.ac after the "expansion", while I end up not being so lucky with it before expansion.

Looks more like a bug than a question of luck to me. There's no further down the configure.ac the snippet could be moved so that would mean $exec_prefix cannot be used in configure.ac at all. Which looks like a bug to me.

[martinpitt]

I can confirm that. It also happens with building Python 2 extensions. It also happens in a Fedora 25 mock build, with a plain

 ./autogen.sh && ./configure && make -j4 && make install DESTDIR=`pwd`/i/`

I get i/NONE/lib64/python3.5/site-packages/bytesize/bytesize.py.

So my guess is that rpmbuild just happens to set --exec-prefix?

[martinpitt]

I'll dissect this tomorrrow (just can't assign this issue to me).

[vpodzime]

So my guess is that rpmbuild just happens to set --exec-prefix?

Must be something else because ./autogen.sh && ./configure runs just fine on my Fedora 25 in the git repository.

[vpodzime]

I'll dissect this tomorrrow (just can't assign this issue to me).

Thanks a ton!

[martinpitt]

@vpodzime: yes, that bit works; try make install DESTDIR=/tmp/i/ && find /tmp/i and check where the Python modules end up.

[vpodzime]

@vpodzime: yes, that bit works; try make install DESTDIR=/tmp/i/ && find /tmp/i and check where the Python modules end up.

Interesting. I have never cared about that. :)