Hi - this isn't really a bug but more of a request. It would seem that when APR is installed, it created its own version of libtool. This libtool seems to store a large amount of system information such as CFLAGS which makes source-based distributions problematic. The real issue is that is forms a dependency on what /bin/sh is. Many systems have this as a symlink, and programs that depend on APR will fail to compile if the link is changed. Please be sure that the scripts that control APR and its libtool never assume that /bin/sh is bash (even if it was when APR was built, subsequent invocations shouldn't assume it hasn't change).If you need bash extensions, call /bin/bash.
Can you identify a particular bash-ism that gets baked in? I thought libtool went out of its way to write portable /bin/sh.
Created attachment 32193 [details] Diffs showing problem (not a fix)
Nice - Attaching a file wiped out my comment. Knew I should have saved it. Anyway, I just wanted to mention that I know its kinda nit-picky but I'm going through all the software that makes /bin/sh assumptions. APR is better about it since it only makes the assumption if /bin/sh is indeed bash at the time its compiled. But it creates a file (libtool) that has #!/bin/sh at the top and uses bourne extensions, in this case +=. Now if I change my /bin/sh link, I have to recompile apr. I plan on doing this anyway since its stores so much information about my system in that file that I don't know if its safe to have it dynamically source it at run-time or not. I'm planning on rebuilding it and all dependencies of it if I make a change to something like CFLAGS, just to be safe. But ... having to recompile a library every time I change a symlink is kinda annoying. It would be better if put #!/bin/bash when it used the extensions or simply never used the extensions at all. Thats a lot of code to detect which way it should work and I don't think it will noticeably improve anything by using the extensions when available. Someone went through a lot of work to make this fragile.
This is an upstream (libtool) issue AFAICT, and APR doesn't have an influence on it. Possibly the libtool configuration respects envvars that can be used to work around the problem, such as hard-coding the shell to a path that is always bash. The libtool docs say The current libtool implementation is done with a shell script that needs to be invoked by the shell that configure chose for configuring libtool (see The Autoconf Manual in The Autoconf Manual). This shell is set in the she-bang (‘#!’) line of the libtool script. Using a different shell may cause undefined behavior. Maybe this part of the autoconf manual describes something you need to use: http://www.gnu.org/software/autoconf/manual/autoconf.html#CONFIG_005fSHELL
One workaround: If you set CONFIG_SHELL=/bin/bash during compilation, you get a libtool that uses /bin/bash instead of /bin/sh. Debian does this for example.