Fri 31 Jul 2015 12:29:31 AM UTC, comment #31:
I can finally reproduce this! Debian testing with TERM="xterm-basic" and overriding the system readline with a readline-6.2 build:
|
Thu 30 Jul 2015 08:30:47 PM UTC, comment #30:
Thank you for re-opening it and running it to ground
|
Thu 30 Jul 2015 07:42:32 PM UTC, comment #29:
Same to you all.
"This is why we can't have nice things" is often said around here since we're "stuck" with CentOS 6 variants and the extremely dated package libraries.
|
Thu 30 Jul 2015 07:34:40 PM UTC, comment #28:
Thanks both of you for testing a few things for me. I think I have a handle on this, I will try to reproduce a little bit later. I think this bug is going to mostly affect CentOS (and RHEL) 6 and 7 users.
Here's what I think is happening. Readline has always printed out the terminal code to enable "8-bit meta mode" (named smm), if the terminal has such a code defined (in the terminfo database).
In CentOS 5, there was no smm defined for xterm, or any terminals in the entire terminfo database in fact.
In CentOS 6, several xterm* terminals do have smm defined, including the base "xterm" itself.
Readline version 6.1 added an option to allow the 8-bit meta enable code to be disabled (enable-meta-key) if the user wants, the default is enabled (if available, as it has been for years). CentOS 6 has readline 6.0, so there is no way to bypass this.
Readline version 6.3 fixed this so that the enable-meta code is not sent when output is not a tty.
Debian and Ubuntu are not affected because they have a different terminfo database that does not define the smm code for xterm (but does for terms like "xterm-basic" and "xterm-utf8").
So this is really a bug in readline, and primarily affecting CentOS users who have an old readline and a terminfo database with this escape sequence enabled for xterm (and xterm-16color, and xterm-256color, but not xterm-color!).
I'll do a little more exploring to confirm all of this, and thanks again for persisting and helping me figure out which pieces are interacting to make this happen. I'll think about what would be a decent workaround to protect against this.
|
Thu 30 Jul 2015 07:23:08 PM UTC, comment #27:
I confirmed what Anonymous reported. On Centos 7 the terminal window has TERM=xterm-256 color. If I start octave from this terminal and try to do pkg install communications-1.2.1.tar.gz I get the failure that I noted before. If I exit out of octave, and change the TERM environment variable to TERM=vt100, re-enter octave and pkg install communications-1.2.1.tar.gz, this completes successfully.
|
Thu 30 Jul 2015 05:31:30 PM UTC, comment #26:
I'm going to shelve this unless you all have a better solution for CentOS 6 users than this. I changed my gnome-terminal profile preferences (under Title and Command) to Run a custom command instead of my shell which I set to:
env TERM=xterm-color /bin/bash
Now every time I start a gnome-terminal, it's setup to handle this whole escape sequence issue if I ever run into it again.
Thanks again for your time and help re-opening this for me.
|
Thu 30 Jul 2015 05:26:30 PM UTC, comment #25:
So to confirm, TERM=xterm produces this escape sequence when you are on a local gnome-terminal? Or is it a different TERM? And you are using bash as a shell? But TERM=<<same terminal>> does not produce the escape sequence when logged in via ssh? And TERM=vt100 fixes it locally or via ssh?
Can you look at a diff of your entire shell environment in the working vs. not-working states? I usually do "env | LC_COLLATE=C sort > file.txt".
Can you try a different terminal emulator, xterm or rxvt or konsole, any differences there?
Your inputrc looks pretty standard. Do you happen to have a ~/.inputrc (in your HOME directory)?
What is the output of "infocmp | grep 1034"?
|
Thu 30 Jul 2015 04:36:10 PM UTC, comment #24:
And here's this as well:
http://stackoverflow.com/questions/15760712/python-readline-module-prints-escape-character-during-import
Setting my TERM environment variable to vt100 prior to starting octave allowed the communications package to compile as if I logged in via ssh.
Honestly I don't see how this is a useful solution though since the TERM variable is set to xterm when I ssh too, so it's not quite the problem; it's just the difference of being a tty or not.
|
Thu 30 Jul 2015 03:50:16 PM UTC, comment #23:
Found this:
[link](https://bugzilla.redhat.com/show_bug.cgi?id=304181)
It seems to blame the configure script but acknowledges the issue is related to the terminal/readline interaction. For what it's worth, my inputrc is attached.
(file #34557)
|
Thu 30 Jul 2015 03:41:18 PM UTC, comment #22:
Another observation -- the ssh environment doesn't define a COLORTERM variable, but the local environment does (gnome-terminal).
Mark, on your CentOS setup, are you using gnome-terminal?
|
Thu 30 Jul 2015 03:34:29 PM UTC, comment #21:
I'm trying to dig into the inputrc/readline setup to see if there are any differences in the environment when I ssh vs. being local in gnome-terminal. I tried comparing the output of `bind -P` (as well as V and S) between those two and there were no differences.
Is there another way I can help with the readline theory?
|
Thu 30 Jul 2015 03:24:31 PM UTC, comment #20:
A couple of additional observations. There seems to be a lot of conversation on the hdf5 web sites regarding configuration issues from recent updates. When I went back to starting with a clean Centos 6 system, I installed the standard repository octave ( which I think was 3.8.x). I then installed the packages control, signal, and communications using that version and everything built fine. Then I installed octave 4.0.0 and the toolkits remained from the prior installation so I had the configuration I wanted.
Then I started with a clean Centos 7 build, installed all the dependencies that octave 4.0.0 wanted ( ~ 65 installs) and built octave and it seemed to build fine. Then toolkit control and signal built fine, but communications gave me the save error I had gotten on earlier attempts.
I did two kluges to get it to build. I unpacked the communications tar and modified the line in ov-galois.h referencing hid_t which is not defined. I forced it to be an int. The second change to avoid the invalid argument error in the later compiles was to edit Makefile.in and force the HDF5_CPPFLAGS and HDF5_LDFLAGS to be empty. Whatever was being defined were invalid character sequences. Then I re tar the package and pkg install worked perfectly. I have not tested everything exhaustively to see if anything broke, but initial tests showed comm functions working fine.
|
Thu 30 Jul 2015 02:43:30 PM UTC, comment #19:
Indeed.
The command outputs were the same.
The first:
/usr/local/bin/octave-4.0.0 --norc --no-history --silent --eval 'disp(octave_config_info.HDF5_CPPFLAGS)' | hexdump -C
- 1b 5b 3f 31 30 33 34 68 0a |.[?1034h.|
00000009
And the second:
/usr/local/bin/octave-4.0.0 --norc --no-history --silent --no-line-editing --eval 'disp(octave_config_info.HDF5_CPPFLAGS)' | hexdump -C
- 1b 5b 3f 31 30 33 34 68 0a |.[?1034h.|
00000009
As for INPUTRC, how can I help? It's not set on my system (echo $INPUTRC is empty). I tried setting it and re-running the pkg install for communications, but it failed the same as before.
The version of readline that is available to us is 6.0-4.el6 (if that helps).
|
Thu 30 Jul 2015 02:32:11 PM UTC, comment #18:
Yes I would still like to address this so it's not a problem.
I'd like to see if the --no-line-editing option helps. I'd also like to see if setting the INPUTRC environment variable to /dev/null helps. Even better if you could tell me which particular readline configuration option is doing it.
I'm using gnome-terminal on various CentOS and Debian systems and I haven't ever seen this, I think it might be environment or readline configuration-depdendent.
|
Thu 30 Jul 2015 02:29:56 PM UTC, comment #17:
I see that, let's see where it's coming from. What's the output of the following on your system?
then try the same with the --no-line-editing option added.
I think this escape sequence is coming from readline, I am not sure which configuration option is doing that because it doesn't for me.
|
Thu 30 Jul 2015 02:28:32 PM UTC, comment #16:
Thanks so much for that tip on how to get the config log. That was the key to unraveling a bit what's going on.
That escape sequence seems to be related to what terminal I'm using (gnome-terminal, default installed) when running Octave. If I ssh into my system (ssh me@localhost) and re-run the octave-cli, I can install the communications package (config.log loses that escape sequence it pulled from the HDF5_LDFLAGS, etc.).
So chalking this up to a local environment problem is certainly a true statement, but surely it can be overcome by a less...hackish way to handle the terminal.
|
Thu 30 Jul 2015 01:57:53 PM UTC, comment #15:
That seems to have worked for me too, thanks. There seems to be some strange escape sequence being inserted, ^[[?1034h, which results in a "No such file or directory" error on the first configure check. Results are attached.
(file #34556)
|
Thu 30 Jul 2015 01:42:18 PM UTC, comment #14:
I think the best way to mimic the install process without deleting the intermediate would be to unpack the tarball, go into an Octave shell, cd to the src directory in Octave, and
This works for me, prints the configuration lines that I expect, and now there is a config.log and Makefile in the src directory. If that works for you, please attach the full config.log and I'll compare it against what I have on a working system and see why those "no" responses are coming out.
|
Thu 30 Jul 2015 01:36:01 PM UTC, comment #13:
Thank you; I really appreciate it.
Is there a way dump the config.log out of the pkg install process? It always deletes the temporary directory even if I interrupt the build process.
I also tried pkg build with a separate build directory, but it failed saying that it needs the signal package (which is installed, along with control).
Trying to run configure from the 'src' directory of the communications tarball is also not a help (nothing but environment and script variable errors).
|
Thu 30 Jul 2015 01:18:03 PM UTC, comment #12:
Sorry anonymous, this bug report does actually look closer to the error you are seeing, I'm reopening it. Can you attach the config.log file that is created during the communications package build? If the directory is cleaned up you may have to unpack the tarball and build it manually.
And gkeperling, if you have any further information about how you got it working on your system, please share.
|
Thu 30 Jul 2015 12:59:02 PM UTC, comment #11:
And I would prefer to remain anonymous. It's pretty clear to me from this person's setup below that we're hitting a very similar if not identical build problem which is why I posted to it.
I would be happy to open an additional bug with my statement, below, if you would prefer, since that interface permits anonymous posts.
|
Thu 30 Jul 2015 12:34:57 PM UTC, comment #10:
I'm asking you to start a thread on the help mailing list.
|
Thu 30 Jul 2015 11:45:45 AM UTC, comment #9:
Any chance a resolution ever came from the mailing list thread (if one was created)?
I'm having something similar on CentOS 6.6 64-bit between two systems (i.e., comment #7).
One system, this error somehow resolved itself over a configure-make battery of reinstalling after apparently making no changes to the OS (looking at my bash history and my notes on the matter).
Now on a new system, I've gone through my notes and repeated everything, but the communications package still will not compile correctly against HDF5 (so far as I can tell). The primary differences between the two systems when installing the communications package (-verbose) is below:
pkg install -forge communications -verbose
mkdir (/tmp/oct-eaXuh5)
untar (/root/communications-1.2.1.tar.gz, /tmp/oct-eaXuh5)
checking for mkoctfile... /usr/local/bin/mkoctfile-4.0.0 --verbose
checking for octave... /usr/local/bin/octave-4.0.0
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for a sed that does not truncate output... /bin/sed
checking for Octave HDF5 preprocessor flags...
checking for Octave HDF5 linker flags...
checking for Octave HDF5 libraries... -lhdf5
checking for octave_hdf5_id type... no
checking for octave_base_value::gripe_load and octave_base_value::gripe_save... no
Those last 2 lines are 'yes' on the working system. That difference then tacks on '-DHAVE_OCTAVE_HDF5_ID_TYPE=1' and '-DHAVE_OCTAVE_BASE_VALUE_GRIPE_LOAD_SAVE=1' to the compiler commands. So in that much, this issue is similar to the one in comment #2 in that perhaps installation should abort when these flags are 'no' rather than proceed, because ultimately this error occurs:
In file included from gf.cc:41:
ov-galois.h:41: error: ‘hid_t’ does not name a type
g++ -shared -Wl,-Bsymbolic -o genqamdemod.oct genqamdemod.o -L/usr/local/lib/octave/4.0.0 -L/usr/local/lib -loctinterp -loctave
make: *** [gf.o] Error 1
make: *** Waiting for unfinished jobs....
In file included from op-gm-gm.cc:26:
ov-galois.h:41: error: ‘hid_t’ does not name a type
make: *** [op-gm-gm.o] Error 1
make: Leaving directory `/tmp/oct-TGVEyR/communications-1.2.1/src'
So in essence, having HAVE_OCTAVE_HDF5_ID_TYPE not defined and HAVE_HDF5 defined results in somehow not having access to that type in hdf5 even though Octave's configure log indicates it found a usable version of hdf5.
I have the same versions of 'hdf5', 'hdf5-devel', and 'hdf5-static' packages installed on both systems. I've also verified the file from comment #4 is the same in both cases. The the only set of HDF5 flag that Octave defined during compilation is '-lhdf5' (as shown above).
I've tried looking at the 'configure.ac' file for the communications package, but I'm having trouble tracing back how to get both of those flags to be true (so that I can test to see if whatever drives that would solve this for me).
Where should I start looking for how to get those flags to be set?
|
Mon 13 Jul 2015 06:44:27 PM UTC, comment #8:
Please do keep investigating your configuration and feel free to comment again here if you find the resolution. But if you want to have a discussion and get help from others (myself included) please start a thread on the help mailing list instead, that would be more productive than continuing any discussion here. Thanks.
|
Mon 13 Jul 2015 03:38:36 PM UTC, comment #7:
One step backward. When I removed octave and all the packages and started again from the beginning I ended up in the same configuration where I could not install the communications package. Will continue to pursue but could not so far replicate whatever changed to allow communications to build. So I agree that it is not a communications package issue; most probably a octave install as you suggested. Just cannot figure out what is missing.
|
Sat 11 Jul 2015 04:31:58 PM UTC, comment #6:
Thanks for following up that you got it working. Closing as works for me since it was a local configuration problem. Feel free to continue to comment here, or on the help mailing list, if you find what was causing the error and think it would be useful to document.
|
Fri 10 Jul 2015 06:32:40 PM UTC, comment #5:
Not sure what caused the change but was now able to install the communications toolkit successfully. I am going back to a clean install and try and re-create situation.
I verified that all required dependencies were installed. They were.
Then just for fun I ran the ./configure.status executable again.
Then did make check
Then did sudo make install
After this octave let me do the pkg install of the communications tookkit.
Thenks for your guidance and help. I will post anything new I learn when I go through the whole procedure from scratch again
|
Fri 10 Jul 2015 05:02:31 PM UTC, comment #4:
Yes, as far as I could tell the make completed successfully. I ran make check and then ran make install. In response to your question, yes the header file /usr/local/include/octave-4.0.0/octave/oct-hdf5-id.h is present and the contents are:
The summary for the make check process resulted in:
PASS 12875
FAIL 0
XFAIL 17
SKIPPED 64
If it helps I can supply those tests that were skipped.
|
Fri 10 Jul 2015 01:38:27 AM UTC, comment #3:
Something looks wrong with your Octave installation. Are you sure you built and installed Octave 4.0 correctly, including a full 'make install'?
Do you have the file /usr/local/include/octave-4.0.0/octave/oct-hdf5-id.h? What are the file contents?
|
Thu 09 Jul 2015 09:53:30 PM UTC, comment #2:
Here is the complete output up to the failure point.
I did notice a difference in the example you posted and this output - the octave_hdf5_id type is yes in your example and no in the text below and gripe_save is yes in your example and no in the text below
|
Thu 09 Jul 2015 08:29:05 PM UTC, comment #1:
Thanks for your bug report. I can't reproduce this error. Are you sure your Octave 4.0.0 installation was done completely and correctly?
Can you paste the configure part of the communications package install output, the lines that start with "checking for" and "checking whether"? I get the following:
|
Thu 09 Jul 2015 07:09:12 PM UTC, original submission:
Running Centos 6.6 inside virtualBox. Octave 4.0.0 builds fine and pkg install of control-2.8.3 and signal-1.3.2 completes fine. pkg install --verbose for communications-1.2.1 fails with lines:
|