CMake Server: Docs mismatch, clarification needed - cmake

I was running across this piece of documentation: https://cmake.org/cmake/help/v3.13/manual/cmake-server.7.html
But as it turns out, the description given on how to start the server, is not the same as shown in the documentation. When executing cmake -E server --debug, I am getting the following message:
CMake Error: No protocol versions defined. Maybe you need --experimental?
When adding the suggested flag --experimental, the server will launch, reading from standard input and responding to standard output, as expected. However, all the examples shown on the documentation do not suggest the use of this flag. Plus, I have version 3.13.4 installed as well.
What is the proper way of starting the CMake server, as in how would I specify the protocol version, and why am I asked to use --experimental?
My main goal is to find out if I can extract values like targets and their associated information (like CFLAGS) off CMake. Using this server command would certainly let me do this by just writing a small piece of NodeJS code to interact with it.

Related

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.

SystemTap semantic error when trying to run dvorak-qwerty script

I found this repo with a systemtap script for letting me use QWERTY ctrl-shortcuts on my dvorak layout. Unfortunately, I can't get it to work, but I don't think it has to do with the script itself. I'm running Pop OS and I think that it's because the linux-image I need with all the debug symbols doesn't exist.
The script says I need to install linux-headers-$(uname -r) linux-image-$(uname -r)-dbg
For me, this turns into linux-headers-5.11.0-7620-generic linux-image-5.11.0-7620-generic-dbg
linux-headers-5.11.0-7620-generic exists and I'm able to download it using apt-get.
linux-image-5.11.0-7620-generic-dbg can't be installed using apt-get. I can install
linux-image-5.11.0-7620-generic, but that's not the same thing. I've spent time looking online for it and adding different keys to apt-get, but I haven't been able to find anything with that name. If the problem is not having the correct linux-image package installed, I need help being pointed in the right direction as to where I can get it.
I tried following the directions here, and I've also searched this to no avail. I tried downloading and installing linux-image-4.4.0-142-generic-dbgsym_4.4.0-142.168_amd64.ddeb but that also didn't work.
If this isn't the problem, I've provided the output of the script. Any help is appreciated.
peyton#pop-os:~/scripts$ sudo stap -g -v dvorak-qwerty.stp
Pass 1: parsed user script and 477 library scripts using 116428virt/91336res/7612shr/83628data kb, in 140usr/30sys/168real ms.
semantic error: resolution failed in DWARF builder
semantic error: resolution failed in DWARF builder
semantic error: while resolving probe point: identifier 'module' at dvorak-qwerty.stp:152:7
source: probe module("evdev").function("evdev_events") {
^
semantic error: no match
semantic error: resolution failed in DWARF builder
Pass 2: analyzed script: 2 probes, 0 functions, 1 embed, 0 globals using 119016virt/94812res/8680shr/86216data kb, in 10usr/0sys/7real ms.
Pass 2: analysis failed. [man error::pass2]
Tip: /usr/share/doc/systemtap/README.Debian should help you get started.
Yes, debuginfo downloading has been a pain on many distros. However, if you're running Debian kernels, see: https://wiki.debian.org/Debuginfod for instructions on using a new automated system. Generally: https://sourceware.org/elfutils/Debuginfod.html .

Connecting R to Snowflake through ODBC

I have been consistently receiving the same error while trying to create a connection between R and Snowflake using an ODBC driver. The error that I'm receiving says:
'''Error during wrapup: nanodbc/nanodbc.cpp:1021: 00000: [unixODBC][Driver Manager]Can't open lib 'Snowflake' : file not found
Error: no more error handlers available (recursive errors?); invoking 'abort' restart'''
The instructions given by Snowflake to connect a driver are rather cut and clear - but provides little insight on what to do with errors. Can anyone lead me as to where to go given this error?
This smells like a configuration issue. Your driver manager, unixODBC, isn't able to locate the Snowflake driver. (The Snowflake documentation says on MacOS to use iODBC. Don't. It won't work with the odbc R package.)
Check that unixODBC is findable. Run odbcinst -j in a terminal. If it works, you will know that you have unixODBC properly installed, and it will give you the paths to your various configuration files.
On to checking configuration. This is the documentation for configuring on Linux using unixODBC. If you are using MacOS the same general instructions apply, but the file extensions will change from .so to .dylib . Since it's saying it can't find the file, I'm thinking that using full paths might resolve this for you. It's also possible that there's some issue with how you are specifying the driver.
Also, it looks like it's searching for a file named 'Snowflake'. I'm thinking you've got Driver=Snowflake somewhere in one of your config files. Best change that to Driver=<path>/<to>/<driver>/libSnowflake.dylib (or .so if you're on Linux). Do this in all the places where you have Driver=Snowflake.

<PATH_TO_SUMO>/bin/netedit: symbol lookup error: /usr/lib/libgdal.so.20: undefined symbol: ecs_SetReportErrorFunction

Error:
<PATH_TO_SUMO>/bin/netedit: symbol lookup error: /usr/lib/libgdal.so.20: undefined symbol: ecs_SetReportErrorFunction
This error appears when I try to run netedit. I have both the Webots simulation software, as well as the SUMO simulation software in my system and both, have netedit. When I remove either one of the software and then run netedit, it works. So, I think the issue is because of the presence of netedit twice. I was running netedit directly from the terminal but even after I give the exact path of the netedit I want to run, in a python script, and then run that script(For eg: I give the path of the netedit in SUMO), it shows this error. How to force the system to use a particular netedit (either webots' or SUMO's) whenever the netedit command is given?
This should be a question of setting your environment variable(s) PATH (and possibly LD_LIBRARY_PATH) to the correct values. If you install SUMO via the package manager of your Linux (apt or something) there should be nothing to adapt. I see from the Webots docs that they recommend manual adaption of those paths. If you don't do those changes or revert them you should be always using the netedit coming with plain SUMO. If you want to use the Webots version adapt the paths such that they list Webots directories first.

pg_bulkload error: "FATAL: unrecognized configuration parameter "wal_level""

I'm trying to give pg_bulkload a try.
When I try to use the postgresql executable it provides, I get the following error:
/usr/local/src/pg_bulkload-3.0.1/bin> ./postgresql start -D /pg_data
server starting
/usr/local/src/pg_bulkload-3.0.1/bin>
FATAL: unrecognized configuration parameter "wal_level"
Google turned up an exact match for this error when someone was using a 9.0 version of psql to run a script on an instance of Postgres 8.4. I don't see how that could be related to my case--I have two versions of Postgres, but I'm sure I'm pointing at the right directory... any thoughts are very welcome.
As far as I can tell from the docs, PostgreSQL 9.x supports a configuration parameter named "wal_level", but version 8.4 does not. The postgresql.conf file for my 9.0.something server has that parameter; the one for my 8.4 server does not.
PostgreSQL 9.x server configuration
PostgreSQL 8.4 server configuration
Your error message suggests you're running version 8.4, but it's reading the configuration file for a 9.x server. Check your postgresql.conf and installation process. I'm thinking pg_bulkload might have "helped" you in ways you didn't anticipate.
I think that it can be a bit tricky to install pg_bulkload to the right place if you have more than one version of PostgreSQL installed on your machine. My first problem was that pg_bulkload (version 3.1.6) could not find pg_port library. I copied the library libpgport.a (a static library) to /usr/local/lib where it was found, but this approach is not recommended, because this is only a quick fix that doesn't work at the end. So, very soon there was another problem: "undefined reference to `pstrdup'". I reckon that in pg_bulkload there should be a possibility of pointing out where PostgreSQL is installed. Well, I changed Makefile of pg_bulkload in pg_bulkload-3.1.6/bin, namely line with PG_LIBS: PG_LIBS = $(libpq) -L/current location of your PostgreSQL/PostgreSQL/pgsql/lib -lpgport -lpgcommon. -lpgport has to be added before -lpgcommon. Last but not least, to compile and install pg_bulkload you shoud modify your PATH: PATH=/current location of your PostgreSQL/PostgreSQL/pgsql/bin:$PATH make USE_PGXS=1 [install]; This makes sure that your pg_bulkload will be added to the correct version of PostgreSQL (in my case 9.3). Enjoy!