bugGNU Octave - Bugs: bug #45509, [octave forge] (communications)...

 
 

bug #45509: [octave forge] (communications) version 1.2.1 fails during package install in octave-4.0.0

Submitter:  None
Submitted:  Thu 09 Jul 2015 07:09:12 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Installation Failure
Status:  Works For Me Assigned to:  mtmiller
Originator Name:  kep Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * other
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 27 Feb 2020 11:55:47 PM UTC, comment #32: 

Nothing has been done for this extremely edge case bug, but time has passed, the communications package now works with Octave 4.4 and later, and I'm not sure how to reproduce this anymore. Closing as working. If there continue to be build or install errors with the communications package in current versions of Octave, please file bugs.

Mike Miller <mtmiller>
Group Member
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:


$ LD_LIBRARY_PATH=$HOME/src/readline/shlib TERM=xterm-basic ./run-octave --norc --no-history --silent --eval 'disp(pi)' | cat -A
^[[?1034h 3.1416$

$ AWK=mawk LD_LIBRARY_PATH=$HOME/src/readline/shlib TERM=xterm-basic octave-cli
octave:1> more off
octave:2> pkg install -forge -verbose communications
## Same error as reported here


Mike Miller <mtmiller>
Group Member
Thu 30 Jul 2015 08:30:47 PM UTC, comment #30: 

Thank you for re-opening it and running it to ground

Gary Keperling <gkeperling>
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.

Anonymous
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.

Mike Miller <mtmiller>
Group Member
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.

Gary Keperling <gkeperling>
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.

Anonymous
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"?

Mike Miller <mtmiller>
Group Member
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.

Anonymous
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)

Anonymous
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?

Anonymous
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?

Anonymous
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.

Gary Keperling <gkeperling>
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
00000000  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
00000000  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).


Anonymous
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.

Mike Miller <mtmiller>
Group Member
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?


/usr/local/bin/octave-4.0.0 --norc --no-history --silent --eval 'disp(octave_config_info.HDF5_CPPFLAGS)' | hexdump -C


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.

Mike Miller <mtmiller>
Group Member
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.

Anonymous
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)

Anonymous
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


octave:1> setenv ("MKOCTFILE", [octave_config_info.bindir, filesep, "mkoctfile-", OCTAVE_VERSION])
octave:2> setenv ("OCTAVE", [octave_config_info.bindir, filesep, "octave-", OCTAVE_VERSION])
octave:3> system ("./configure")


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.

Mike Miller <mtmiller>
Group Member
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).

Anonymous
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.

Mike Miller <mtmiller>
Group Member
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.

Anonymous
Thu 30 Jul 2015 12:34:57 PM UTC, comment #10: 

I'm asking you to start a thread on the help mailing list.

Mike Miller <mtmiller>
Group Member
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?


Anonymous
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.

Mike Miller <mtmiller>
Group Member
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.

Gary Keperling <gkeperling>
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.

Mike Miller <mtmiller>
Group Member
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

Anonymous
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:

/*

Copyright (C) 2015 John W. Eaton

This file is part of Octave.

Octave is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 3 of the License, or (at your
option) any later version.

Octave is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for more details.

You should have received a copy of the GNU General Public License
along with Octave; see the file COPYING.  If not, see
<http://www.gnu.org/licenses/>.

*/

#if !defined (octave_oct_hdf5_id_h)
#define octave_oct_hdf5_id_h 1

typedef int octave_hdf5_id;

extern bool check_hdf5_id_type (bool warn = true);

#endif


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.

Gary Keperling <gkeperling>
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?

Mike Miller <mtmiller>
Group Member
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


>> pkg install /home/gk27360/Downloads/communications-1.2.1.tar.gz -verbose
mkdir (/tmp/oct-0v0fuC)
untar (/home/gk27360/Downloads/communications-1.2.1.tar.gz, /tmp/oct-0v0fuC)
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
checking whether octave_base_value::print is const-qualified... no
configure: creating ./config.status
config.status: creating Makefile

make: Entering directory `/tmp/oct-0v0fuC/communications-1.2.1/src'
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES __errcore__.cc -o __errcore__.oct
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES __gfweight__.cc -o __gfweight__.oct
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES cyclgen.cc -o cyclgen.oct
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES cyclpoly.cc -o cyclpoly.oct
g++ -c  -fPIC -I/usr/local/include/octave-4.0.0/octave/.. -I/usr/local/include/octave-4.0.0/octave -I/usr/local/include -pthread -fopenmp -g -O2    -DGALOIS_DISP_PRIVATES __gfweight__.cc -o __gfweight__.o
g++ -c  -fPIC -I/usr/local/include/octave-4.0.0/octave/.. -I/usr/local/include/octave-4.0.0/octave -I/usr/local/include -pthread -fopenmp -g -O2    -DGALOIS_DISP_PRIVATES __errcore__.cc -o __errcore__.o
g++ -c  -fPIC -I/usr/local/include/octave-4.0.0/octave/.. -I/usr/local/include/octave-4.0.0/octave -I/usr/local/include -pthread -fopenmp -g -O2    -DGALOIS_DISP_PRIVATES cyclgen.cc -o cyclgen.o
g++ -c  -fPIC -I/usr/local/include/octave-4.0.0/octave/.. -I/usr/local/include/octave-4.0.0/octave -I/usr/local/include -pthread -fopenmp -g -O2    -DGALOIS_DISP_PRIVATES cyclpoly.cc -o cyclpoly.o
g++ -shared -Wl,-Bsymbolic  -o __errcore__.oct  __errcore__.o   -L/usr/local/lib/octave/4.0.0 -L/usr/local/lib-loctinterp -loctave
g++ -shared -Wl,-Bsymbolic  -o __gfweight__.oct  __gfweight__.o   -L/usr/local/lib/octave/4.0.0 -L/usr/local/lib -loctinterp -loctave
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES genqamdemod.cc -o genqamdemod.oct
g++ -c  -fPIC -I/usr/local/include/octave-4.0.0/octave/.. -I/usr/local/include/octave-4.0.0/octave -I/usr/local/include -pthread -fopenmp -g -O2    -DGALOIS_DISP_PRIVATES genqamdemod.cc -o genqamdemod.o
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES -c galois-def.cc -o galois-def.o
g++ -c  -fPIC -I/usr/local/include/octave-4.0.0/octave/.. -I/usr/local/include/octave-4.0.0/octave -I/usr/local/include -pthread -fopenmp -g -O2    -DGALOIS_DISP_PRIVATES galois-def.cc -o galois-def.o
g++ -shared -Wl,-Bsymbolic  -o cyclgen.oct  cyclgen.o   -L/usr/local/lib/octave/4.0.0 -L/usr/local/lib -loctinterp -loctave
g++ -shared -Wl,-Bsymbolic  -o cyclpoly.oct  cyclpoly.o   -L/usr/local/lib/octave/4.0.0 -L/usr/local/lib -loctinterp -loctave
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES -c galois.cc -o galois.o
g++ -c  -fPIC -I/usr/local/include/octave-4.0.0/octave/.. -I/usr/local/include/octave-4.0.0/octave -I/usr/local/include -pthread -fopenmp -g -O2    -DGALOIS_DISP_PRIVATES galois.cc -o galois.o
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES -c galoisfield.cc -o galoisfield.o
g++ -c  -fPIC -I/usr/local/include/octave-4.0.0/octave/.. -I/usr/local/include/octave-4.0.0/octave -I/usr/local/include -pthread -fopenmp -g -O2    -DGALOIS_DISP_PRIVATES galoisfield.cc -o galoisfield.o
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES -c gf.cc -o gf.o
g++ -c  -fPIC -I/usr/local/include/octave-4.0.0/octave/.. -I/usr/local/include/octave-4.0.0/octave -I/usr/local/include -pthread -fopenmp -g -O2    -DGALOIS_DISP_PRIVATES gf.cc -o gf.o
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES -c op-gm-gm.cc -o op-gm-gm.o
g++ -c  -fPIC -I/usr/local/include/octave-4.0.0/octave/.. -I/usr/local/include/octave-4.0.0/octave -I/usr/local/include -pthread -fopenmp -g -O2    -DGALOIS_DISP_PRIVATES op-gm-gm.cc -o op-gm-gm.o
g++ -shared -Wl,-Bsymbolic  -o genqamdemod.oct  genqamdemod.o   -L/usr/local/lib/octave/4.0.0 -L/usr/local/lib-loctinterp -loctave
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES -c op-gm-m.cc -o op-gm-m.o
g++ -c  -fPIC -I/usr/local/include/octave-4.0.0/octave/.. -I/usr/local/include/octave-4.0.0/octave -I/usr/local/include -pthread -fopenmp -g -O2    -DGALOIS_DISP_PRIVATES op-gm-m.cc -o op-gm-m.o
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES -c op-gm-s.cc -o op-gm-s.o
g++ -c  -fPIC -I/usr/local/include/octave-4.0.0/octave/.. -I/usr/local/include/octave-4.0.0/octave -I/usr/local/include -pthread -fopenmp -g -O2    -DGALOIS_DISP_PRIVATES op-gm-s.cc -o op-gm-s.o
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES -c op-m-gm.cc -o op-m-gm.o
g++ -c  -fPIC -I/usr/local/include/octave-4.0.0/octave/.. -I/usr/local/include/octave-4.0.0/octave -I/usr/local/include -pthread -fopenmp -g -O2    -DGALOIS_DISP_PRIVATES op-m-gm.cc -o op-m-gm.o
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES -c op-s-gm.cc -o op-s-gm.o
g++ -c  -fPIC -I/usr/local/include/octave-4.0.0/octave/.. -I/usr/local/include/octave-4.0.0/octave -I/usr/local/include -pthread -fopenmp -g -O2    -DGALOIS_DISP_PRIVATES op-s-gm.cc -o op-s-gm.o
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES  -c ov-galois.cc -o ov-galois.o
mkoctfile: unrecognized argument
make: *** [ov-galois.o] Error 1
make: *** Waiting for unfinished jobs....
make: Leaving directory `/tmp/oct-0v0fuC/communications-1.2.1/src'
tmp/oct-0v0fuC/communications-1.2.1/src
pkg: error running `make' for the communications package.
error: called from 'configure_make' in file /usr/local/share/octave/4.0.0/m/pkg/private/configure_make.m near line 97, column 9


Anonymous
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:


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... yes
checking for octave_base_value::gripe_load and octave_base_value::gripe_save... yes
checking whether octave_base_value::print is const-qualified... no


Mike Miller <mtmiller>
Group Member
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:

....
/usr/local/bin/mkoctfile-4.0.0 --verbose -DGALOIS_DISP_PRIVATES -c ov-galois.cc -o ov-galois.o
mkoctfile: unrecognized argument
make: *** [ov-galois.o] Error 1
make: *** Waiting for unfinished jobs....
make: Leaving directory `/tmp/oct-9DuhID/communications-1.2.1/src'
tmp/oct-9DUhID/communications-1.2.1/src
pkg: error running `make' for the communications package.
error: called from 'make_configure' in file /usr/local/share/octave/4.0.0/m/pkg/private/configure_make.m near line 97, column 9


Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #34557:  inputrc added by None (942B - application/octet-stream - CentOS 6.6 inputrc configuration)
file #34556:  config.log added by None (14KiB - text/x-log - config.log from communications-1.2.1 configure)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by gkeperling (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-27 mtmiller StatusNeed Info Works For Me
        Open/ClosedOpen Closed
    2017-08-13 jwe Summarycommunications-1.2.1 fails during package install in octave-4.0.0 [octave forge] (communications) version 1.2.1 fails during package install in octave-4.0.0
    2016-03-31 mtmiller Item GroupBuild Failure Installation Failure
        Operating SystemOther GNU/Linux
    2016-03-19 mtmiller Dependencies- bugs #47466 is dependent
    2015-07-30 None Attached File- Added inputrc, #34557
    2015-07-30 None Attached File- Added config.log, #34556
    2015-07-30 mtmiller StatusWorks For Me Need Info
        Open/ClosedClosed Open
    2015-07-11 mtmiller StatusNeed Info Works For Me
        Open/ClosedOpen Closed
    2015-07-09 mtmiller StatusNone Need Info
        Assigned toNone mtmiller
        Release4.0.0 other

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code