mapnik configure fails during rpmbuild, but succeeds manually - awk

I've posted this issue on the google groups area for mapnik already, so I'm just going to c/p from there:
I've been troubleshooting this issue for a couple days, now. Bear with me for context:
Starting from a freshly-untarred source of mapnik 2.2.0 on RHEL 6.5:
First off, running "./configure" (which just calls scons/scons.py) works great. Finishes correctly, then I run make + make install and I get exactly what I want built and installed.
My goal has been to create a mapnik 2.2.0 RPM for internal use. Please do not suggest using an "official" mapnik RPM instead (or any other already-built mapnik RPM), as my entire purpose here is to build mapnik from source and create my own RPM.
That being said, when my RPM gets to its %build phase and runs ./configure, it freezes while scons checks for freetype-config. I've let it sit for hours, and nothing happens.
After I looked at the generated config.log file, it would appear that configure is failing on an "awk" command that goes something like this:
awk '{print $\(NF-1\)}'
The command is performed on the string that results from the command:
/usr/bin/freetype-config --libs --cflags
I'm wondering, first of all, how to fix this, but second of all why this would work manually, but fail when the rpmbuild process gets to the ./configure command. I've made sure that the same user (myself) is running both ./configure commands on the exact same files.
My third question would be: why does the configure step freeze on this issue, instead of throwing some sort of error and stopping?
Note that the problem with the "awk" command is the backslashes--the error is:
awk: {print $\(NF-1\)}
^ backslash not last character on line
When I remove the backslashes, the command succeeds. Whether or not removing the backslashes is the correct thing to do in the long run, I do not know.
It would seem this is some sort of python string-parsing / encoding issue, but I'm unsure. What really confuses me is why this works manually and fails when the rpmbuild tries to do it.
My only thought is that there's some difference between the rpmbuild environment and my shell that I configured on. What it is, I do not know.
Thank you for any assistance you can provide. If I can provide any more context, please let me know.
UPDATE: an svn command runs after the awk failure, but is missing whatever number gets passed after the -r option. I'm wondering if this could be causing the hang...thoughts?

Related

WSL can't detect VS code

At first, I tried to fix my problem of npm instruction
so I added
[interop]
appendWindowsPath = false
to /etc/wsl.conf
It works, but another problem happen.
When I type code .
Command 'code' not found, did you mean:
command 'node' from deb nodejs (12.22.9~dfsg-1ubuntu3)
command 'cdde' from deb cdde (0.3.1-1build1)
command 'ode' from deb plotutils (2.6-11)
command 'tcode' from deb emboss (6.6.0+dfsg-11ubuntu1)
command 'cde' from deb cde (0.1+git9-g551e54d-1.2)
Try: sudo apt install <deb name>
The above Error message appear.
I tried the following instruction
export PATH=$PATH:"/mnt/c/Users/%USERNAME%/AppData/Local/Programs/Microsoft VS Code/bin"
It also works properly.
Whenever I restarted WSL, npm instruction still worked well, but code instruction lost its function again.
What should I do to fix the problem?
Thanks in advance!
My main suggestion would be to not use appendWindowsPath = false to fix your NPM problem. That's like using a sledgehammer as a flyswatter. As I said in this answer:
Please do not follow the recommendations (like this answer) to completely remove all Windows paths from WSL, as that will severely limit your ability to run Windows applications in WSL (one of its great features).
You'll also lose access to the ability to run PowerShell scripts and commands in WSL easily. You won't have direct access to wsl.exe itself from inside WSL (which comes in handy).
You can type the full paths to these commands, of course, but most instructions and other answers you find here are going to assume that you've left the Windows path intact.
Instead, figure out where npm is installed in your WSL distribution and then determine why it is further toward the end of the PATH than your Windows directories. Windows paths are added at the end of the Linux PATH for a reason. If something in your startup files is adding to the path, it should put it at the beginning, so it has precedence. E.g.:
export PATH="newdir:$PATH"
Note that I'm not saying that you should change your export statement above since, as mentioned, that Windows path would normally come at the end anyway. It's really not going to matter unless you put another code executable somewhere else in your path.
Whenever I restarted WSL, npm instruction still worked well, but code instruction lost its function again.
If you do want the "quick and dirty" (not recommended) solution, then you can simply add that export command that "makes it work" to your ~/.bashrc. That file is processed each time the Bash shell starts interactively.

OPUS Make error: OPUS MAKE: Unknown status. Stop

We are using OPUS Make in our build infrastructure. (Basically traditional make with some wrappers around I guess)
Our codebase is mostly Java and I have been making changes and building for many months now. No issues.
Suddenly, a couple of days back, when I tried to build,i started seeing this error:
OPUS MAKE: Unknown status. Stop.
I see this error no matter what I try to build. More imp - it looks like it is not even trying to actually compile my code and for some reason just stops before with the above error.
I tried doing a clean build. Even manually cleaned up all old generated build files. Still did not work.
I even tried restarting my environment itself. Restarted Clearcase. Still no use.
I see there is a way to build with debug information. Did that also make -d
However, that did not give any useful info either. Just the same line as above. I was hoping that it would give some debug logs or some error code that I could use to solve the problem.
I see there is an option: make -n. That comes out clean. But from the name, it looks like it does not even attempt to run the build itself.
Please suggest what the issue could be.
thx - Om
"Unknown status" means that a shell command in a target returned a status that make did not understand. Run with -d to see which command is failing. And debug that shell command.

Apache log4cxx 0.12.0 cmake scripts fail during test configuration

Version: apache-log4cxx-0.12.0.tar.gz
Configuration:
mkdir build; cd build && cmake -DBUILD_SHARED_LIBS=off -DAPR_STATIC=yes -DAPU_STATIC=yes ..
Symptoms (log snippet):
32882 error: downloading 'https://www-us.apache.org/dist/logging/log4j/1.2.17/log4j-1.2.17.tar.gz' failed
32883 status_code: 6
32884 status_string: "Couldn't resolve host name"
32885 log:
32886 --- LOG BEGIN ---
This was building just last month. I can't 100% attest to the fact that the build procedure has not changed (since it was done manually) but I don't believe it was significantly different.
At first, I thought my DNS resolver was just out of date, but after some dig-ing and fiddling with /etc/resolv.conf, it has become apparent that the www-us.apache.org url log4cxx was using to get the tarball from has disappeared from the face of the earth.
Two methods you can use to fix this (which I wish someone had posted before me).
First
Hack your /etc/hosts file to spoof www-us.apache.org to actually go to www.apache.org (where you will find a redirect for the link). To give neophytes an idea of what I'm talking about, here is kinda how I did it on Debian.
sudo echo '151.101.2.132 www-us.apache.org' >> /etc/hosts
Second
Fix the cmake script src/test/java/CMakeLists.txt line 3 to point to the right link. The broken one is
https://www-us.apache.org/dist/logging/log4j/1.2.17/log4j-1.2.17.tar.gz
The right one is
https://downloads.apache.org/logging/log4j/1.2.17/log4j-1.2.17.tar.gz
Digging around the GitHub account we found this code merged and (I assume) ready to go out with the next release, whenever that is.
https://github.com/apache/logging-log4cxx/commit/341a23aa0d13278c8ae85b6017d49de9790f00fe
Here's hoping this helps someone not remain stuck, expecting the build to work like it did a month ago.

How can I make mumps when I make bonmin

The tested platform is windows using cygwin. I download bonmin-1.8.8 from https://www.coin-or.org/download/source/Bonmin/.
First, I obtained the third party code with the commands
./get.asl
./get.blas
./get.lapack
./get.mumps
then ran the command
./configure -C
and it shows that the configuration of bonmin is successful.
But then, when I run
make
There's something wrong with the makefile of Mumps.
It shows a rank mismatch between the actual arguments at (1) and (2)
MUMPS/src/dmumps_comm_buffer.F:2670:23:
I want to know how can I successfully make it?

building apache from source on debian

I'm trying to build apache from source on debian. The only reason I'm not using spt-get install is because in the apache cookbook, they recommend installing from source.I get the following error when I ./configure:
configure: error: invalid variable name: ' --with-mpm'
I also saw some warnings when I ./buildconf Is this something I should be concerned about? This is my first attempt at compiling from source, and I'd really appreciate any help.
I'm using the ./configure arguments directly from the apache cookbook:
./configure --prefix=/usr/local/apache --with-layout=Apache --enable-modules=most --enable-mods-shared=all \ --with-mpm=prefork
I'm running a minimum debian install in virtual box to train myself for deploying in the rackspace cloud soon.
EDIT: I'm building Apache 2.2.16
I suspect you are typing that entire build line you provided on one line, complete with the '\' in the middle.
You should get rid of '\', which in bash either treats the following as part of the same string, but the slash has to immediately follow a non-whitespace character. It is also used for special escape sequences, which I think is the case here and generating that message.
This should be the correct line in your case.
./configure --prefix=/usr/local/apache --with-layout=Apache --enable-modules=most --enable-mods-shared=all --with-mpm=prefork
On a side note, doesn't the Apache Cookbook say that building from source is one possibility for installing it, in addition to installing from a pre-packaged build like you can get from Debian's repositories? I suppose if you really wanted a far newer build or a more repeatable process to ensure consistency across a variety of distributions, building from scratch will do that for you, but otherwise I would try to utilize the distribution's package management as much as possible. Building from source removes you from the security patches and ease-of-upgrade path that Debian APT gives you.