bugGNU Octave - Bugs: bug #54235, problems building Octave on Solaris

 
 

bug #54235: problems building Octave on Solaris

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Mon 02 Jul 2018 08:47:17 PM UTC  
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  4.4.0 Operating System:  Solaris/SunOS

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Sun 22 Jul 2018 12:44:24 AM UTC, comment #150:

That's worth a try. I deleted the 5.5 directory again and untarred a new one. I created a gccbuild directory and ran configure --disable-Werror from there and then gmake all. Unfortunately, this doesn't seem to have helped.

Michele <michele31415>
Sat 21 Jul 2018 07:36:29 PM UTC, comment #149:

I think you should start by extracting the 5.5 src code from the tarball again (don't want to rely on distclean target). I'm going to say that the directory where you untar that is gccsrc. From the directory that contains gccsrc, make a new directory gccbuild. The structure is now

Then do

Rik <rik5>
Project Administrator
Sat 21 Jul 2018 04:19:13 PM UTC, comment #148:

I just keep sinking deeper. In the 5.5 directory I did

and gmake ended with

But I have a C++ compiler:

Michele <michele31415>
Sat 21 Jul 2018 03:48:56 PM UTC, comment #147:

You are referring to this section:

I did see that but I took it as not applying here since I did not specify any --prefix flag to ./configure. I thought they meant "don't dump the tar file in /usr/local/ and build there". I'm building in my home directory and they claim the default installation directory is /usr/local.

Am I reading this wrong? If so, how should I be invoking configure? They don't give any examples. I simply called it with only --disable-Werror for options.

Michele <michele31415>
Sat 21 Jul 2018 01:03:30 AM UTC, comment #146:

It also appears that you building in the source tree. As far as i remember this was not recommended.

https://gcc.gnu.org/install/configure.html

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 21 Jul 2018 12:34:35 AM UTC, comment #145:

Don't know what happened to the end of my last post. It should say:

./configure --disable-Werror
gmake

And it's still not happy:

Note how near the end we're back to "cc1: all warnings being treated as errors".

Michele <michele31415>
Sat 21 Jul 2018 12:29:48 AM UTC, comment #144:

I tried setting:

but got the same fpermissive error. So I reset both flags to "-fpermissive" and ran

Michele <michele31415>
Sat 21 Jul 2018 12:12:12 AM UTC, comment #143:

I'd try unsetting CFLAGS and CXXFLAGS in your environment and start a fresh build. You shouldn't need to specify those to build GCC. I think it was a bug of some sort that you ran into with the other build.

John W. Eaton <jwe>
Project Administrator
Fri 20 Jul 2018 11:55:51 PM UTC, comment #142:

Well 5.5 failed too, but with fewer errors:

Michele <michele31415>
Fri 20 Jul 2018 08:05:09 PM UTC, comment #141:

I will try building 5.5 locally.

Michele <michele31415>
Fri 20 Jul 2018 08:02:33 PM UTC, comment #140:

Does self-building gcc 5.5 have similar issues? Maybe try not to go all the way to version 6.4.

Rik <rik5>
Project Administrator
Fri 20 Jul 2018 07:56:29 PM UTC, comment #139:

Hmm, well searching for this fpermissive business on the gnu bug list turns up someone else with this problem:

The proposed solution seems to be "comment out the definitions cousing the errors", which seems a bit odd to me. Anyway, I just created a new report over there. We'll see if they have any ideas about this or the subsequent errors. I know I don't.

Michele <michele31415>
Fri 20 Jul 2018 04:39:27 PM UTC, comment #138:

One thing I note is that the first error is still caused by -fpermissive and for whatever reason, -fpermissive hasn't made it through to the list of options for xg++.

Maybe start by solving that problem before tackling the second one.

Rik <rik5>
Project Administrator
Fri 20 Jul 2018 04:15:38 PM UTC, comment #137:

Sigh - I meant verbatim, not verbose. I really wish there was some way to edit, or at least remove posts here once they've been posted.

Michele <michele31415>
Fri 20 Jul 2018 04:13:44 PM UTC, comment #136:

"just add this flag to your CFLAGS and CXXFLAGS variables."

That was great. It actually went further this time, but it's still stopping here:

+verbose+
gmake[3]: Entering directory '/export/home/michele/gcc-6.4.0/host-sparc-sun-solaris2.10/gcc'
/export/home/michele/gcc-6.4.0/host-sparc-sun-solaris2.10/prev-gcc/xg++ -B/export/home/michele/gcc-6.4.0/host-sparc-sun-solaris2.10/prev-gcc/ -B/usr/local/sparc-sun-solaris2.10/bin/ -nostdinc++ -B/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs -B/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs -I/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/include/sparc-sun-solaris2.10 -I/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/include -I/export/home/michele/gcc-6.4.0/libstdc++-v3/libsupc++ -L/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs -L/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../.././gcc -I../.././gcc/build -I../.././gcc/../include -I./../intl -I../.././gcc/../libcpp/include \
-o build/genmddeps.o ../.././gcc/genmddeps.c
In file included from ./bconfig.h:3:0,
from ../.././gcc/genmddeps.c:18:
./auto-host.h:2321:16: error: declaration does not declare anything [-fpermissive]
#define rlim_t long
^
In file included from ../.././gcc/genmddeps.c:19:0:
../.././gcc/system.h:496:48: error: ‘char* strstr(const char*, const char*)’ conflicts with a previous declaration
extern char strstr (const char , const char *);
^
In file included from /usr/include/string.h:18:0,
from /export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/include/cstring:42,
from ../.././gcc/system.h:235,
from ../.././gcc/genmddeps.c:19:
/usr/include/iso/string_iso.h:119:20: note: previous declaration ‘const char* std::strstr(const char*, const char*)’
extern const char strstr(const char , const char *);
^~~~~~
In file included from ../.././gcc/genmddeps.c:19:0:
../.././gcc/system.h:540:20: error: conflicting declaration of C function ‘const char* strsignal(int)’
extern const char *strsignal (int);
^~~~~~~~~
In file included from /export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/include/cstring:42:0,
from ../.././gcc/system.h:235,
from ../.././gcc/genmddeps.c:19:
/usr/include/string.h:79:14: note: previous declaration ‘char* strsignal(int)’
extern char *strsignal(int);
^~~~~~~~~
gmake[3]: *** [Makefile:2497: build/genmddeps.o] Error 1
gmake[3]: Leaving directory '/export/home/michele/gcc-6.4.0/host-sparc-sun-solaris2.10/gcc'
gmake[2]: *** [Makefile:4425: all-stage2-gcc] Error 2
gmake[2]: Leaving directory '/export/home/michele/gcc-6.4.0'
gmake[1]: *** [Makefile:21971: stage2-bubble] Error 2
gmake[1]: Leaving directory '/export/home/michele/gcc-6.4.0'
gmake: *** [Makefile:909: all] Error 2
#
-verbose-

As usual, I have no idea what it's talking about.

Michele <michele31415>
Fri 20 Jul 2018 02:40:46 AM UTC, comment #135:

The documentation for -fpermissive is:

Since you don't really care whether the gcc6.4 code is meeting whatever standards are expected, you could just add this flag to your CFLAGS and CXXFLAGS variables.

Rik <rik5>
Project Administrator
Thu 19 Jul 2018 11:48:10 PM UTC, comment #134:

Well after hours of compiling, gcc 6.4 finally failed with a series of cryptic error messages. I'm not expecting anyone here to help debug gcc so I'm not even posting them all but for the curious it includes stuff like:

Michele <michele31415>
Thu 19 Jul 2018 07:35:02 PM UTC, comment #133:

"You can try 6.4.x"

OK then I'll give that a try. I'm downloading 6.4.0 now. A custom site-built gcc might avoid the errors I was getting from csw's gcc 5.

Michele <michele31415>
Thu 19 Jul 2018 04:49:42 PM UTC, comment #132:

It is also not that difficult to build gcc from source.
One problem is that one usually cannot jump too far from your existing gcc. So I would guess with 4.x.x. you should be able
to build 5.5.x, but most likely not 7.x.x. You can try 6.4.x

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 19 Jul 2018 04:40:01 PM UTC, comment #131:

@Michele: I can't say definitively, but I do believe that moving to gcc5 will help with the other libraries as well. You want to be closer to what is considered "normal", neither bleeding edge versions of packages nor deprecated, obsolote ones.

Rik <rik5>
Project Administrator
Thu 19 Jul 2018 04:12:09 PM UTC, comment #130:

As I recall, the code for arithmetic on int64 types relies on some bit-twiddling code written by the same person who wrote the bit-flipping code to test the BLAS library for 4- or 8-byte integers. My guess is that it doesn't do the right thing on big-endian systems.

You didn't really get very far into the tests before the crash happened in the syscalls test.

We'll need more info to figure out what's going on there.

John W. Eaton <jwe>
Project Administrator
Thu 19 Jul 2018 04:03:41 PM UTC, comment #129:

"I think the next step should be to try and move up to gcc 5."

I don't mind trying that if you think it will help. It's just really slow. The bottleneck appears to be opencsw's download speeds. It literally takes two hours just to get the gcc package from them.

Would this help fix all my "-without-this and that" problems too?

Michele <michele31415>
Thu 19 Jul 2018 03:58:37 PM UTC, comment #128:

"You can try to run the failing tests on the octave command line"

Thanks for the tip, I didn't know that. I got this:

No idea what to make of any of that though.

Michele <michele31415>
Thu 19 Jul 2018 03:16:39 PM UTC, comment #127:

I think the next step should be to try and move up to gcc 5. I believe this stands a chance of fixing the problem in pr-output.cc that still requires applying abs.diff to the source tree each time.

Moving to gcc 5 is more of a Solaris / packaging activity. The bugs need to be worked out so that a simple C++ program can be compiled under C++11 standards.

Rik <rik5>
Project Administrator
Thu 19 Jul 2018 12:58:23 AM UTC, comment #126:

You can try to run the failing tests on the octave command line,
e.g.:

and then inspect and/or post log files to see what actually is failing.

See "help test" for details.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 18 Jul 2018 11:47:47 PM UTC, comment #125:

I was also able to get gmake test to run this time:

Seems to be mostly a passing score but with sort of a strange ending though.

Michele <michele31415>
Wed 18 Jul 2018 08:09:41 PM UTC, comment #124:

"Here is a new link for a tar.lz file which contains a fix for the big endian / little endian problem"

That worked. It configured and gmaked successfully, so I now have a working "without-everything" subset of Octave:

Michele <michele31415>
Wed 18 Jul 2018 03:38:37 AM UTC, comment #123:

@Michele: Here is a new link for a tar.lz file which contains a fix for the big endian / little endian problem (bug #53853).

https://spideroak.com/storage/OVPXG4DJMRSXE33BNNPWC5LUN5PTEMJUG44DE/shared/1331845-1-4584/octave-4.4.1-rc1.tar.lz?7615f72ce35a583df8a6a61439016e29

You should be able to extract the archive, apply only Mike's patch "abs.diff", configure as before, and then gmake.

Rik <rik5>
Project Administrator
Mon 16 Jul 2018 08:22:20 PM UTC, comment #122:

Personally I am dividing the list into the things that Octave can do something about and the things that are up to the porter / system administrator to do something about.

I would like to close this bug report as resolved now, because we have Octave building on Solaris, there is no bug here now. Does anyone object to closing this as fixed?

The two other bug numbers I referenced are real bugs in Octave that can be fixed by changing something in Octave, with more hands on testing.

The remaining issues 3 through 7 are all system configuration and packaging issues that are outside the scope of Octave. It's not like Octave isn't compatible with a different version of something, or Octave is making a wrong assumption about the size of an integer or other common porting problems. These are issues like including <GL/glext.h> causes a compiler error. I think most or all of these could be reduced to very simple standalone test cases and reported to the OpenCSW packagers or support forums or whatever, and see what can be done about these.

Mike Miller <mtmiller>
Project Administrator
Mon 16 Jul 2018 07:49:33 PM UTC, comment #121:

I'd also be interested to see whether mxe-octave would build current tools and all dependencies properly. If so, then I would treat Solaris the same as old RHEL or SuSE systems that have obsolete tools installed by default.

John W. Eaton <jwe>
Project Administrator
Mon 16 Jul 2018 07:40:16 PM UTC, comment #120:

I'm ambivalent about points 3 and 7. I don't want to waste a lot of energy supporting outdated compilers. If Octave was to drop gcc 4.XX support then we could skip point 3. On the other hand, gcc5 did seem to be a huge issue on Solaris. How certain are we that it wasn't just a mangled installation? Would a clean Solaris install (maybe choosing the POSIX version) followed by adding gcc5 work?

Rik <rik5>
Project Administrator
Mon 16 Jul 2018 07:11:21 PM UTC, comment #119:

Here is my best attempt at a summary of the various issues here, including the things that I had Michele patch out of the build.

Only points 2 and 3 below have to do with the Octave source itself, the rest are entirely system configuration issues.

1. Automake assumes the 'id' program will be POSIX compliant, Michele has moved the Solaris 'id' program out of the way and symlinked 'gid' so that 'id' is now GNU. This was more of a visual annoyance than a fatal error, it is only needed for Automake to know how to build a tar file for 'make dist'.

2. bug #53853 - the configure test for BLAS integer size only works on little endian machines, the sed command in comment #115 works around that by forcing the test to declare the integer size is 4 bytes.

3. bug #54237 - the 'abs' local function template in pr-output.cc has problems with some interaction with the Solaris system and C++ header files with GCC 4.9.2. I do not see these problems with GCC 4.8 on an Ubuntu system, so it is not just the compiler version. At the moment I am assuming a newer compiler might fix this, or that we will rework this hack in pr-output.cc at some point.

4. The freetype.pc pkg-config configuration on Michele's system is somehow mixing or confusing /usr/sfw and /opt/csw. All other development packages installed in /opt/csw are only linking with libraries in /opt/csw. When /usr/sfw/lib is pulled in by freetype.pc, the build tries to link with two different instances of libstdc++.so and libgomp.so (comment #78).

5. The GraphicsMagick package available from OpenCSW was built with GCC 5 and using GCC's new C++11 ABI. Therefore the symbol table is not compatible with GCC 4.9.2 and cannot be linked in with this build (comment #65).

6. The OpenGL header files on this system seemed to have some missing type problems that I don't understand (comment #52).

7. Upgrading to GCC 5 seemed to be a disaster, the g++ 5 compiler was unable to compile a very trivial C++11 program at all with the '-std=gnu++11' option (comment #32).

Mike Miller <mtmiller>
Project Administrator
Mon 16 Jul 2018 05:27:06 PM UTC, comment #118:

"What was the final configure command that you had to use to make this work? Which packages and features had to be disabled?"

"I'd be willing to look at that if I can get a login on a big-endian system."

I'd be more than happy to give you an account on my machine.

Michele <michele31415>
Mon 16 Jul 2018 04:53:21 PM UTC, comment #117:

What was the final configure command that you had to use to make this work? Which packages and features had to be disabled?

If the fortran integer problem is due to bug #53853, then I'd be willing to look at that if I can get a login on a big-endian system.

John W. Eaton <jwe>
Project Administrator
Mon 16 Jul 2018 04:21:37 PM UTC, comment #116:

Hey Mike, it looks like your sed magic spell did the trick! Check it out:

And a quick benchmark:

This is on a Sun M3000 quad-core 2.75 GHz. SPARC64 VII. For comparison, this code on my fastest PC, an Intel Core 2 Duo 3.16 GHz. dual-core took 0.0630 seconds in Matlab 6R13. So that's not too bad.

With that done, is there a way to address the other issues now? Most of my applications are graphics, image processing, and network communication, so I really need those functions. And the GUI.

Michele <michele31415>
Sun 15 Jul 2018 11:31:04 PM UTC, comment #115:

Assuming you are still working from the same partially built directory, here are the steps you should take to try working around this bug and building again.

1. make distclean
2. gsed -i 's/\(ax_blas_integer_size\|sizeof_fortran_integer\)=8/\1=4/g' configure
3. run the same configure command and gmake as before

In case the command doesn't show up correctly above, here it is in a verbatim block

Mike Miller <mtmiller>
Project Administrator
Sun 15 Jul 2018 07:23:24 PM UTC, comment #114:

"What is OCTAVE_F77_INT_TYPE defined to in config.h?"

"If it is int64_t, then you are now hitting bug #53853."

Good guess :-)

config.log is here:

Michele <michele31415>
Sun 15 Jul 2018 05:54:27 PM UTC, comment #113:

Ok. The qrp.cc source file uses 'MArray<F77_INT> to pass an integer array into a Fortran function (the JPVT argument to the xGEQP3 set of LAPACK functions).

On your system the 'F77_INT' type should be defined to be 'int', but I believe it is now being defined to be 'long long'.

What is OCTAVE_F77_INT_TYPE defined to in config.h?

If it is int64_t, then you are now hitting bug #53853.

In the previous build on your system that bug was not hit.

If that's the case can I get a copy of this config.log to confirm that?

And if that is the case, then I can provide a patch for your configure file to try building again to work around this issue.

Mike Miller <mtmiller>
Project Administrator
Sun 15 Jul 2018 03:56:35 PM UTC, comment #112:

I did:

"On my system, there are no objects that reference that symbol."

Well that's odd then. On mine there are three (or maybe two if there lines for liboctave all reference liboctave_numeric_libnumeric)

"I would look at the source code to try to see why it would be referenced, and maybe try to see if something has changed in that source file or related to why that symbol was not a problem in the last build."

I hate to ask a dumb question, but where is the source code? For example, I looked in octave-4.4.0x/liboctave/numeric but only found references to liboctave_numeric_libnumeric_la-qrp.lo.

"If you still have the previous build,"

No, that got overwritten when I did this one.

Michele <michele31415>
Sat 14 Jul 2018 09:44:01 PM UTC, comment #111:

Here's what I would look at.

I would grep through the built object files to find which objects are referencing the symbol '_ZmIIxER6MArrayIT_ES3_RKS1_'.

For example, "grep -Rl ZmIIxER6MArrayIT_ES3_RKS1 liboctave libinterp src".

On my system, there are no objects that reference that symbol.

If I change the symbol to '_ZmIIiER6MArrayIT_ES3_RKS1_' (int instead of long long), then I do find the symbol. It is defined in the source file liboctave/array/MArray-i.cc, and it is used by the symbol liboctave/numeric/qrp.cc.

Assuming I found the object file that references that symbol, I would look at the source code to try to see why it would be referenced, and maybe try to see if something has changed in that source file or related to why that symbol was not a problem in the last build.

If you still have the previous build, I would also search that build directory to see if the symbol used to be defined and now isn't, or if the symbol was not defined and was not needed, but now is needed for some new reason.

Mike Miller <mtmiller>
Project Administrator
Sat 14 Jul 2018 04:24:48 PM UTC, comment #110:

Uh oh. Well this is unfortunately something I'm definitely not going to be able to figure out on my own. Is there a path forward from here?

Michele <michele31415>
Sat 14 Jul 2018 12:56:42 AM UTC, comment #109:

The actual error message

suggests that the 'long long' variant of the function template 'operator-=(MArray<T>&, const T&)' is not being built in liboctave.

I'm not sure what changed that is now causing this error to appear where it didn't appear with the previous 4.4.0x source snapshot.

It could be my change e8961d677661, but if it is, this is some interaction between C++ and the Solaris system header files that I don't understand.

Mike Miller <mtmiller>
Project Administrator
Fri 13 Jul 2018 11:37:45 PM UTC, comment #108:

Using the newest 4.4.0x, I did

./configure --without-opengl --without-qt --without-fltk --disable-java --without-magick --without-fontconfig --without-freetype

This ended without erros so I did gmake.

That gave:

So we're back to the libstdc problem again. Though it seems different this time.

Michele <michele31415>
Fri 13 Jul 2018 07:21:51 PM UTC, comment #107:

"Is this with the original abs.diff or the update that I posted in comment #103?"

It must have been the old version. I downloaded the #103 version and this time it worked.

"try 'id --version'."

Yup.

Michele <michele31415>
Fri 13 Jul 2018 07:06:38 PM UTC, comment #106:

> Unfortunately, after starting with a fresh untar of the latest 4.4.0x and then applying abs.diff, I still get


Is this with the original abs.diff or the update that I posted in comment #103? I downloaded Rik's tarball, unpacked it, and applied the update to abs.diff and it applies cleanly for me.

> So I think it's OK after all. It's just that /usr/bin/id now points to /opt/csw/bin/gid. I guess "which" does not follow links, yes?


May depend on your shell and your 'which' implementation. If you really want to know if it worked, try 'id --version'. That's usually something that only works with the GNU variants of common shell utilities.

Mike Miller <mtmiller>
Project Administrator
Fri 13 Jul 2018 06:51:56 PM UTC, comment #105:

"For the other problem, does this work?"

So I think it's OK after all. It's just that /usr/bin/id now points to /opt/csw/bin/gid. I guess "which" does not follow links, yes?

Michele <michele31415>
Fri 13 Jul 2018 06:48:36 PM UTC, comment #104:

"1. Please start by deleting the entire source tree and unpacking the tar file from scratch.

2. Only apply abs.diff with gpatch, you can throw away pow.diff, it has already been applied to the Octave source tree for 4.4.1 and is included in Rik's tarball already."

Thanks for the clear directions. Unfortunately, after starting with a fresh untar of the latest 4.4.0x and then applying abs.diff, I still get:

Michele <michele31415>
Fri 13 Jul 2018 12:54:59 AM UTC, comment #103:

Here is an updated abs.diff patch, it replaces the previous one you were using.

To summarize:

1. Please start by deleting the entire source tree and unpacking the tar file from scratch.

2. Only apply abs.diff with gpatch, you can throw away pow.diff, it has already been applied to the Octave source tree for 4.4.1 and is included in Rik's tarball already.

3. The 'id' bug isn't that important, if you can't figure out how to make GNU id be the default id program on your PATH, then don't worry about it.

(file #44545)

Mike Miller <mtmiller>
Project Administrator
Fri 13 Jul 2018 12:47:35 AM UTC, comment #102:

Try building with the new tarball. The timestamps will be correct and the build system will not need to re-make the documentation which means you won't require Texlive.

For the other problem, does this work?

Also, what does this show

Rik <rik5>
Project Administrator
Fri 13 Jul 2018 12:46:25 AM UTC, comment #101:

I untarred your new 4.4.0x directory and tried applying the pow patch, and got this:

Michele <michele31415>
Fri 13 Jul 2018 12:19:50 AM UTC, comment #100:

"Alternatively, you could become root and move 'id' aside to a new name like 'sid' for Solaris ID and then soft link 'gid' to 'id'."

OK, so I did:

but it doesn't seem to have worked. What did I do wrong?

Michele <michele31415>
Fri 13 Jul 2018 12:06:28 AM UTC, comment #99:

"You could also run 'make check' to get an idea how functional this version is."

UNfortunately, that didn't work:

I assume it's still wanting Tex, but that's still downloading from csw. I don't know why it's so slow to download.

Michele <michele31415>
Thu 12 Jul 2018 09:24:18 PM UTC, comment #98:

I would assume answering 'yes' would help with these sorts of things.

Rik <rik5>
Project Administrator
Thu 12 Jul 2018 09:16:40 PM UTC, comment #97:

"Solaris 'sh' and 'id' are simply not POSIX compatible"

Well one of the questions the Solaris installer asks when you first set it up from the DVD is do you want POSIX? I said no. Should I have said yes?

Michele <michele31415>
Thu 12 Jul 2018 08:47:47 PM UTC, comment #96:

Basically I think the GNU autotools are correct to require POSIX utilities, and Solaris 'sh' and 'id' are simply not POSIX compatible, so Solaris users have to know to work around these quirks when using portable build systems.

Mike Miller <mtmiller>
Project Administrator
Thu 12 Jul 2018 08:39:54 PM UTC, comment #95:

That is way cool. You now can at least play around in Octave. You could also run 'make check' to get an idea how functional this version is. This command will run the test suite and at the end will print a summary of passed/failed/skipped tests.

I checked on the use of 'id' in configure. I was hoping that Automake would rely on a variable and invoke $(ID) so that the program could be overridden by a variable from Autoconf. But, this is not the case. So, Mike is correct that the configure script needs to have the two instances where "id" is used replaced with "gid".

Alternatively, you could become root and move 'id' aside to a new name like 'sid' for Solaris ID and then soft link 'gid' to 'id'.

Rik <rik5>
Project Administrator
Thu 12 Jul 2018 08:38:00 PM UTC, comment #94:

About the Solaris id program, there is this bug report:

https://lists.gnu.org/archive/html/bug-automake/2015-06/msg00000.html

Looking here:

http://git.savannah.gnu.org/cgit/automake.git/tree/m4/tar.m4

it seems there has been no fix applied.

John W. Eaton <jwe>
Project Administrator
Thu 12 Jul 2018 08:30:19 PM UTC, comment #93:

Use "bash ./run-octave" to avoid these Solaris shell script errors

> Got it. How should I configure it? Same as the last one I did, or go for everything?


1. You should definitely apply the abs.diff patch file that I gave you. This won't be fixed in Octave until we have some better testing or can see that a newer compiler will fix this for you without us needing to do anything.

2. You should still definitely configure with --without-freetype to avoid the buggy conflict between libraries in /usr/sfw and /opt/csw. This seems like a packaging problem on your system.

3. You should still definitely configure with --without-magick because your version of GCC is not compatible with the way the GraphicsMagick library in OpenCSW was built.

You can try removing some of the other without options as you want.

Mike Miller <mtmiller>
Project Administrator
Thu 12 Jul 2018 08:24:25 PM UTC, comment #92:

"Here is a new tarball."

Got it. How should I configure it? Same as the last one I did, or go for everything?

"try run-octave."

Holy moly, that worked:

So I guess that's progress.

Michele <michele31415>
Thu 12 Jul 2018 08:12:52 PM UTC, comment #91:

@Michele: Here is a new tarball. The link will expire in 3 days.

https://spideroak.com/storage/OVPXG4DJMRSXE33BNNPWC5LUN5PTEMJUG44DE/shared/1331845-1-4545/octave-4.4.0x.tar.lz?f7efbd7ae0d3279288b4ce57a0d5fd50

If you are in the directory where Octave has just been built, try run-octave. There won't be a correctly working version of octave in /usr/local/bin until you have done 'make install' which probably hasn't happened yet.

Rik <rik5>
Project Administrator
Thu 12 Jul 2018 07:52:41 PM UTC, comment #90:

Does a patch file to some code in pr-output.cc force a rebuild of the user manual? I wouldn't think so. We have build rules in place that extract the doc strings and only update the timestamps on files if the strings themselves have changed. Since we are only patching code, the user manual should not need to be rebuilt, unless a doc string is actually changed. At least that's the intent, but there may be another latent bug there.

Mike Miller <mtmiller>
Project Administrator
Thu 12 Jul 2018 07:50:15 PM UTC, comment #89:

Rik - the two known problems that have not been addressed on Solaris in the hg repo yet (in any branch) are

  • The Solaris 'id' program does not support the -g and -u options, this is a built-in Autoconf thing, Autoconf expects the user to have an 'id' program that is POSIX compliant. The GNU id program is installed on Solaris as 'gid' only. This can only be fixed by patching configure after running autoconf.
  • GCC 4.9.2 on Solaris fails to build with "error: call of overloaded ‘abs(short int)’ is ambiguous" in pr-output.cc. I have asked for testing with a newer version of GCC on Solaris since I think this may be a compiler / system header problem that may be fixed in a newer version, but I don't know whether that will fix it or not. I would rather not rename the private 'abs' to something else if we don't have to.

The first just prints error messages to the console while configure is running but is not a fatal error.

The second requires a local patch that I have given Michele since it is not fixed in our source repository.

Mike Miller <mtmiller>
Project Administrator
Thu 12 Jul 2018 07:43:12 PM UTC, comment #88:

Try the 'touch' solution. In the mean time, I'll prepare another tarball for you to download. We have applied several patches targeting building on Solaris recently including

It would be good to start from a fresh tarball to see what else needs to be done.

Rik <rik5>
Project Administrator
Thu 12 Jul 2018 07:42:52 PM UTC, comment #87:

> And maybe touch other files that fail to build under the doc directory


Mike Miller <mtmiller>
Project Administrator
Thu 12 Jul 2018 07:39:13 PM UTC, comment #86:

"If the build has moved on to the docs, that means you already have the octave binary itself built successfully."

Oh! I didn't know that. But:

I figured maybe I have to say gmake install, but that gave:

(I did create the octave.dvi and .pdf files).

Michele <michele31415>
Thu 12 Jul 2018 07:23:49 PM UTC, comment #85:

If it were me, I would examine the timestamps of all files that were included in the tar file. They should all be identical, and unchanged from the metadata in the tar file itself. List the files that have newer timestamps.

If all you want to do is get to a finished build, then I would try

And maybe touch other files that fail to build under the doc directory, and keep repeating gmake until it finishes with success.

If the build has moved on to the docs, that means you already have the octave binary itself built successfully.

Mike Miller <mtmiller>
Project Administrator
Thu 12 Jul 2018 07:01:26 PM UTC, comment #84:

So what should I do now?

Michele <michele31415>
Thu 12 Jul 2018 06:54:46 PM UTC, comment #83:

This build step shouldn't be needed. The docs are already included in the source distribution that you got from gnu.org or the snapshot from Rik.

Some build step thinks that some documentation string or something has changed and is trying to regenerate the docs. This is possibly a bug, or possibly means that you have touched the timestamp or modified a file, or that some patch or option that we did in pursuing these build errors has made a modification.

Mike Miller <mtmiller>
Project Administrator
Thu 12 Jul 2018 06:49:06 PM UTC, comment #82:

The latest gmake ended this way:

So now I'm installing texlive from csw.

Michele <michele31415>
Thu 12 Jul 2018 04:51:56 PM UTC, comment #81:

Nope, no editing.

Rik <rik5>
Project Administrator
Thu 12 Jul 2018 04:43:33 PM UTC, comment #80:

The configure command in my last post got clipped when I copied it. The current configure is:

./configure --without-opengl --without-qt --without-fltk --disable-java --without-magick --without-fontconfig --without-freetype

(Is there any way to edit a post here after it's been posted?)

Michele <michele31415>
Thu 12 Jul 2018 04:40:41 PM UTC, comment #79:

Well

fails with

I had to unset LDFLAGS (which got set in some post previously) to get configure to finish successfully. gmake is running right now.

"Does 'env PKG_CONFIG_PATH=/opt/csw/lib/pkgconfig:/usr/local/lib/pkgconfig:/opt/sfw/lib/pkgconfig:/usr/lib/pkgconfig pkg-config --libs freetype2' return '-R/usr/sfw/lib -L/usr/sfw/lib -lfreetype'?"

Yes.

Michele <michele31415>
Thu 12 Jul 2018 01:01:06 AM UTC, comment #78:

This

excerpt from the link command line indicates that FreeType is still being linked into Octave.

You should try configuring with both '--without-fontconfig' and '--without-freetype'. The configure script will still attempt to build and use FreeType library functions even if Fontconfig isn't found or is disabled.

The real culprit here is the FreeType configuration, which is probably coming from a botched pkg-config file with the FreeType packaging on your system.

Does 'env PKG_CONFIG_PATH=/opt/csw/lib/pkgconfig:/usr/local/lib/pkgconfig:/opt/sfw/lib/pkgconfig:/usr/lib/pkgconfig pkg-config --libs freetype2' return '-R/usr/sfw/lib -L/usr/sfw/lib -lfreetype'?

Mike Miller <mtmiller>
Project Administrator
Wed 11 Jul 2018 09:11:08 PM UTC, comment #77:

Sorry - I missed the command line from the second textbox in the previous post:

# echo "int x = 0;" > foo.c ; gcc -v foo.c

(Is there any way to edit a post here after it's been posted?)

Michele <michele31415>
Wed 11 Jul 2018 09:08:41 PM UTC, comment #76:

"What is the definition of FLIBS that Octave's configure script determines?"

"Are the versions of g++, gcc, and gfortran you are using all form the same installation?"

Yes - they're all directly downloaded from Opencsw.

"Can you post the results of executing these commands on your system"

This is what they do:

Michele <michele31415>
Wed 11 Jul 2018 08:54:24 PM UTC, comment #75:

After all the object files and convenience libraries are listed in that final linking command, I see

So for some reason, g++ is linking with things from both /usr/sfw and /opt/csw.

What is the definition of FLIBS that Octave's configure script determines? It should be listed in the summary that configure prints and recorded in the generated Makefile.

Are the versions of g++, gcc, and gfortran you are using all form the same installation? Are they consistent about where they look for headers and library files? You can check that by compiling trivial programs using each:

Can you post the results of executing these commands on your system, and also the value of FLIBS that is in the Makefile?

John W. Eaton <jwe>
Project Administrator
Wed 11 Jul 2018 08:13:04 PM UTC, comment #74:

OK, this is what that gives:

I see a number of references to /bin/bash above but I'm using /opt/csw/bin/bash. I have no idea what the rest of that means.

Michele <michele31415>
Wed 11 Jul 2018 04:37:34 PM UTC, comment #73:

LD_LIBRARY_PATH is used when running an executable, not when the compiler is linking a program or library.

To see if there is a -L option that names that directory, use

To get even more info about exactly what linker command GCC is executing, add "-v" to LDFLAGS, or execute the last link command that fails manually and insert -v in the options. With V=1 passed to make, libtool should show you exactly what it is executing.

John W. Eaton <jwe>
Project Administrator
Wed 11 Jul 2018 04:10:38 PM UTC, comment #72:

OK, so

./configure --without-opengl --without-qt --without-fltk --disable-java --without-magick --without-fontconfig

gave this:

I don't know why it keeps looking in /usr/sfw/lib. It's not even on my LD_LIBRARY_PATH:

# echo $LD_LIBRARY_PATH
/opt/csw/lib:/usr/local/lib:/opt/sfw/lib
#

Michele <michele31415>
Tue 10 Jul 2018 10:26:11 PM UTC, comment #71:

The configure help says

Given that OpenGL is already disabled, we don't need FreeType. You could try adding this to the growing list of options to configure.

Rik <rik5>
Project Administrator
Tue 10 Jul 2018 09:06:43 PM UTC, comment #70:

"Are they the same library? Are they different versions of libstdc++?"

No and yes.

"Why are multiple copies of this library installed in different directories?"

My best guess is that Solaris 10 is delivered with a libstdc++ in /opt/sfw/. This is a brand new install off the Solaris 10U11 DVD. The only changes I made was adding Octave dependencies as I went down the list. The most convenient place to get these is Opencsw so that's what I did. I installed csw's libstd++ not knowing that there was already one there.

"What do those directories mean?"

I'm not sure I understand.

"WHy should I choose to link against one or the other? "

csw is newer than sfw. It's not clear though if you want the newer one or the older one.

"Maybe most importantly, I see that /usr/sfw/lib only shows up in your config.log in the context of the FreeType library. Why is that?"

That's a good question.

"Is this correct? "

Probably not.

"Is this a bug in the FreeType packaging?"

Possibly, though the csw packages usually play well together.

"Is FreeType installed differently from all of the other OpenCSW packages on your system?"

No.

" if you can fix the FreeType -I and -L options in the build, then this /usr/sfw vs /opt/csw error may resolve itself."

OK, how do I do that?

I don't understand why it's even looking in /opt/sfw in the first place. None of my flags include that.

Michele <michele31415>
Tue 10 Jul 2018 06:32:41 PM UTC, comment #69:

And we're back to this problem

Are they the same library? Are they different versions of libstdc++? Why are multiple copies of this library installed in different directories? What do those directories mean? WHy should I choose to link against one or the other?

Maybe most importantly, I see that /usr/sfw/lib only shows up in your config.log in the context of the FreeType library:

Why is that? Is this correct? Is this a bug in the FreeType packaging? Is FreeType installed differently from all of the other OpenCSW packages on your system?

My suspicion is if you can fix the FreeType -I and -L options in the build, then this /usr/sfw vs /opt/csw error may resolve itself.

Mike Miller <mtmiller>
Project Administrator
Tue 10 Jul 2018 06:17:32 PM UTC, comment #68:

"Yeah, so the GrahpicsMagick library is built with g++ 5 with the new C++11 ABI, not compatible with older versions of g++ 4."

Well what about these guys:

Recall that I now have

# echo $LD_LIBRARY_PATH
/bkpool/napleshome/miller/libs:/opt/csw/lib:/usr/local/lib:/opt/sfw/lib
#

"you might want to install ccache"

That was a great suggestion. THanks.

Meanwhile, the latest gmake (the one with the --without-magick config) ended like this:

Should I reenable LD_ALTEXEC or is something new going on now?

Michele <michele31415>
Tue 10 Jul 2018 05:57:36 PM UTC, comment #67:

> _ZN6Magick9CoderInfoC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE


Yeah, so the GrahpicsMagick library is built with g++ 5 with the new C++11 ABI, not compatible with older versions of g++ 4.

Mike Miller <mtmiller>
Project Administrator
Tue 10 Jul 2018 05:08:53 PM UTC, comment #66:

As an aside, you might want to install ccache which caches intermediate compilation results. This speeds up re-compilation time significantly. I can do a full re-build, assuming nothing big has changed, in about 3 minutes.

Rik <rik5>
Project Administrator
Tue 10 Jul 2018 04:55:46 PM UTC, comment #65:

Well thge easiest thing is always the thing for me.

# ./configure --without-opengl --without-qt --without-fltk --disable-java --without-magick

completed with no errors. I then did gmake and that's been grinding along for about an hour now. In the meantime while we're waiting for that:

Michele <michele31415>
Tue 10 Jul 2018 01:59:23 AM UTC, comment #64:

Easiest thing is to add

to your configure. Otherwise re-compiling GraphicsMagick or moving to GCC 5 sound hard.

Rik <rik5>
Project Administrator
Tue 10 Jul 2018 01:07:48 AM UTC, comment #63:

It's very curious to me that your latest config.log does not seem to be affected by bug #53853.

That's correct, but on GNU/Linux big-endian systems this test incorrectly failed and reported the BLAS library integer size to be 8. I thought it would affect any big-endian systems.

Mike Miller <mtmiller>
Project Administrator
Tue 10 Jul 2018 12:48:26 AM UTC, comment #62:

It's possible that the GraphicsMagick undefined symbols is related to the GCC ABI change that happened around the release of GCC 5.1.

I don't know if there is a Solaris objdump command or equivalent, but this is how I would check for this on GNU/Linux

and see whether the results match.

If the symbol is '_ZN6Magick9CoderInfoC1ERKSs', then it was built with the old C++98 ABI naming convention.

If the symbol is '_ZN6Magick9CoderInfoC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE', then it was built with the new C++11 ABI naming convention.

If the GraphicsMagick library contains the new naming scheme, then I don't think it is possible to link Octave against GraphicsMagick using GCC 4.9.2, you will have to drop GraphicsMagick, recompile it yourself using GCC 4.9.2, or try using GCC 5 again.

And all of this may or may not be related to the "multiple inclusion" warning, which may or may not be a fatal problem once we get past this problem.

Mike Miller <mtmiller>
Project Administrator
Tue 10 Jul 2018 12:47:45 AM UTC, comment #61:

The GraphicsMagick I installed in /opt/csw/lib is from Opencsw:
1.3.23,REV=2016.05.05

but the first thing in the LD_LIBRARY_PATH is this:

# echo $LD_LIBRARY_PATH
/bkpool/napleshome/miller/libs:/opt/csw/lib:/usr/local/lib:/opt/sfw/lib

# pwd
/bkpool/napleshome/miller/libs
# ls -l agic
lrwxrwxrwx 1 150026 staff 30 Jun 30 11:52 libMagick++-6.Q16HDRI.so -> libMagick++-6.Q16HDRI.so.5.0.0
lrwxrwxrwx 1 150026 staff 30 Jun 30 11:52 libMagick++-6.Q16HDRI.so.3 -> libMagick++-6.Q16HDRI.so.3.0.0
-rwxr-xr-x 1 150026 staff 586492 Feb 26 2014 libMagick++-6.Q16HDRI.so.3.0.0
lrwxrwxrwx 1 150026 staff 30 Jun 30 11:52 libMagick++-6.Q16HDRI.so.5 -> libMagick++-6.Q16HDRI.so.5.0.0
-rwxr-xr-x 1 150026 staff 666508 Jan 8 2015 libMagick++-6.Q16HDRI.so.5.0.0
lrwxrwxrwx 1 150026 staff 32 Jun 30 11:52 libMagickCore-6.Q16HDRI.so -> libMagickCore-6.Q16HDRI.so.2.0.0
lrwxrwxrwx 1 150026 staff 32 Jun 30 11:52 libMagickCore-6.Q16HDRI.so.2 -> libMagickCore-6.Q16HDRI.so.2.0.0
-rwxr-xr-x 1 150026 staff 2883076 Jan 8 2015 libMagickCore-6.Q16HDRI.so.2.0.0
lrwxrwxrwx 1 150026 staff 32 Jun 30 11:52 libMagickWand-6.Q16HDRI.so -> libMagickWand-6.Q16HDRI.so.2.0.0
lrwxrwxrwx 1 150026 staff 32 Jun 30 11:52 libMagickWand-6.Q16HDRI.so.2 -> libMagickWand-6.Q16HDRI.so.2.0.0
-rwxr-xr-x 1 150026 staff 1392160 Jan 8 2015 libMagickWand-6.Q16HDRI.so.2.0.0
#

Michele <michele31415>
Tue 10 Jul 2018 12:43:35 AM UTC, comment #60:

Other people have reported similar problems on Mac machines when their GraphicsMagick library was compiled with clang but the Octave build process was done with gcc. There could be something similar here.

Rik <rik5>
Project Administrator
Tue 10 Jul 2018 12:30:49 AM UTC, comment #59:

This is getting very close. The newest set of warnings is about GraphicsMagick functions which can't be found by the linker. According to your config log, GraphicsMagick was found and this is the set of compilation flags

What version of GraphicsMagick have you installed?

Mike might know if this is is also related to an ABI issue if the library was compiled with a different C++ compiler than the rest of Octave.

Rik <rik5>
Project Administrator
Tue 10 Jul 2018 12:08:13 AM UTC, comment #58:

Ah ha - that was it. Thanks! I was trying to fix the GL problem and found somewhere on the web that suggested setting CFLAGS. I simply forgot I had done that. I unset it and this time it configured without error. New config.log here:

https://login.filesanywhere.com/fs/v.aspx?v=8c69638c586274a6ab6c

I then ran gmake and it went much longer than any attempt so far but finally ended with this:

Michele <michele31415>
Mon 09 Jul 2018 07:38:14 PM UTC, comment #57:

You have CFLAGS=GLX_GLXEXT_LEGACY, that is not a valid option, that is causing all compilation to fail. You probably wanted CFLAGS=-DGLX_GLXEXT_LEGACY, but even better would be CPPFLAGS=-DGLX_GLXEXT_LEGACY and leave CFLAGS unset.

Mike Miller <mtmiller>
Project Administrator
Mon 09 Jul 2018 07:34:17 PM UTC, comment #56:

Don't know what happened there. I just created a new link and it downloaded OK for me:

https://login.filesanywhere.com/fs/v.aspx?v=8c69638c58626dba6e9a

All the csw stuff is still first:

Michele <michele31415>
Mon 09 Jul 2018 06:59:39 PM UTC, comment #55:

I also get an error with the link, no log file to look at.

The 'id' error can be ignored, that has been there all along and isn't related to any of these problems. The only solution to that error is to patch configure to use 'gid', see comment #13.

Mike Miller <mtmiller>
Project Administrator
Mon 09 Jul 2018 06:52:15 PM UTC, comment #54:

I'm getting a FileShare link error when using the URL you posted in comment #53.

But, the illegal id is probably because your PATH variable is different. I think you need to define your PATH so more of the gnu tools occur before the system-provided ones.

Rik <rik5>
Project Administrator
Mon 09 Jul 2018 06:41:54 PM UTC, comment #53:

OK, using your 4.0.0x directory I got:

Full config.log is here:

https://login.filesanywhere.com/fs/v.aspx?v=8c69638c5860727bb2

I hit this before (see comment 12 below) and it was fixed by comment 20, though on rereading that I can't see how that happened. All my gcc tools are 4.9.2 now. Something I did between there and now must have broken it again.

Michele <michele31415>
Mon 09 Jul 2018 05:34:22 PM UTC, comment #52:

Although kind of strange, the libtool message is only a warning, not an error:

The actual errors start with OpenGL

So, could you go back to configuring a minimal Octave that does not include OpenGL, Qt, or FLTK with

It seems like you might be actually close to building a CLI-version of Octave which would be a good starting point for slowly adding the rest.

Rik <rik5>
Project Administrator
Mon 09 Jul 2018 05:20:05 PM UTC, comment #51:

I found some suggestion on the web to add

#define GLX_GLXEXT_LEGACY

to

/opt/csw/include/GL/glext.h

so I did that and ran gmake again. That actually took care of the GLsizptr and GLintptr errors. But now it's back to the gld vs. ld error:

So I undefined LD_ALTEXEC
and ran gmake again. It went a bit further but now we're back to the "libstdc moved" warnings and the GL error came back. ???

Michele <michele31415>
Sun 08 Jul 2018 08:23:12 PM UTC, comment #50:

Ah yes, but I am now compiling in rik's 4.4.0x directory. Apparently this had the pow patch applied but not the diff patch. I applied the diff patch and stasrted gmake again. This time it ran for an hour and is now stopping here:

We went through this too before. I have in /opt/csw/lib a libstdc++.so that points to libstdc++.so.6.0.20, which is not there.

# pwd
/opt/csw/lib
# ls -l libstd
-rw-r--r-- 1 root bin 12246176 Nov 4 2014 libstdc++.a
-rwxr-xr-x 1 root bin 959 Nov 4 2014 libstdc++.la
-rwxr-xr-x 1 root root 959 Jul 3 19:58 libstdc++.la.old
lrwxrwxrwx 1 root root 19 Jul 7 13:28 libstdc++.so -> libstdc++.so.6.0.20
lrwxrwxrwx 1 root root 19 Jun 22 16:19 libstdc++.so.6 -> libstdc++.so.6.0.21
-rw-r--r-- 1 root bin 2300 Nov 4 2014 libstdc++.so.6.0.20-gdb.py
-rwxr-xr-x 1 root bin 11689172 Oct 13 2017 libstdc++.so.6.0.21
#

So I did this:

# ln -s libstdc++.so.6.0.21 libstdc++.so
# ls -l libstdc++.so
lrwxrwxrwx 1 root root 19 Jul 8 16:16 libstdc++.so -> libstdc++.so.6.0.21
#

and ran gmake again.

Now we're back to those ld "seems to be moved" warnings:

ld: warning: file /opt/csw/lib/libgomp.so: attempted multiple inclusion of file
CXXLD libinterp/liboctinterp.la
libtool: warning: '/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.9.2/../../../libstdc++.la' seems to be moved

That took care of those warnings, but now it's stopping wioth a bunch of GL errors:

So I guess that's some progress at least.

Michele <michele31415>
Sun 08 Jul 2018 06:43:37 PM UTC, comment #49:

We've already resolved that error with the abs.diff patch attached to bug #54237, remember? If you're seeing that abs ambiguous error again, that means you are back to an unpatched 4.4.0.

Mike Miller <mtmiller>
Project Administrator
Sun 08 Jul 2018 06:20:34 PM UTC, comment #48:

I got the idea to prepend my PATH with your libs directory from your successful build of 4.0 on the Sunblade 2500. Then I ran plain ./configure with no args. No other changes. This time it actually finished without errors, though it's still not finding QScintilla.

configure: WARNING: QScintilla library not found; disabling built-in Qt GUI editor

Then I did a plain gmake with no args. This time it went much further than before, running over an hour and a half before finally stopping with this:

...
In file included from /usr/include/stdlib.h:17:0,
from /opt/csw/include/c++/4.9.2/cstdlib:72,
from /opt/csw/include/c++/4.9.2/ext/string_conversions.h:41,
from /opt/csw/include/c++/4.9.2/bits/basic_string.h:2850,
from /opt/csw/include/c++/4.9.2/string:52,
from /opt/csw/include/c++/4.9.2/bits/locale_classes.h:40,
from /opt/csw/include/c++/4.9.2/bits/ios_base.h:41,
from /opt/csw/include/c++/4.9.2/iomanip:40,
from libinterp/corefcn/pr-output.cc:29:
/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.9.2/include-fixed/iso/stdlib_iso.h:163:16: note: long int std::abs(long int)
inline long abs(long _l) { return labs(_l); }
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.9.2/include-fixed/iso/stdlib_iso.h:117:12: note: int std::abs(int)
extern int abs(int);
^
In file included from libinterp/corefcn/pr-output.cc:27:0:
/opt/csw/include/c++/4.9.2/cmath:99:5: note: constexpr typename __gnu_cxx::__enable_if<std::__is_integer<_Tp>::__value, double>::__type std::abs(_Tp) [with _Tp = long long unsigned int; typename __gnu_cxx::__enable_if<std::__is_integer<_Tp>::__value, double>::__type = double]
abs(_Tp __x)
^
libinterp/corefcn/pr-output.cc:1713:3: note: T abs(T) [with T = long long unsigned int]
abs (unsigned T x) \
^
libinterp/corefcn/pr-output.cc:1722:1: note: in expansion of macro ‘SPECIALIZE_UABS’
SPECIALIZE_UABS(long long)
^
gmake[2]: *** [Makefile:18318: libinterp/corefcn/libinterp_corefcn_libcorefcn_la-pr-output.lo] Error 1
gmake[2]: Leaving directory '/export/home/michele/octave-4.4.0x'
gmake[1]: *** [Makefile:26500: all-recursive] Error 1
gmake[1]: Leaving directory '/export/home/michele/octave-4.4.0x'
gmake: *** [Makefile:10208: all] Error 2
#

I'm not even sure just what the Error 1 is here.

There's a longer tail of the gmake here:

https://login.filesanywhere.com/fs/v.aspx?v=8c69638b60606db2b169

Michele <michele31415>
Sun 08 Jul 2018 05:21:44 PM UTC, comment #47:

This was cut off of my comment because of the markup processor.

The code boxes are created on Savannah using 'PLUSverbatimPLUS' and 'MINUSverbatimMINUS' tags, where PLUS and MINUS are the actual symbols (if I type them here, Savannah throws away the entire paragraph).

There is a link above the entry box that says "Rich Markup", which lists all of the markup syntax you can use.

Mike Miller <mtmiller>
Project Administrator
Sun 08 Jul 2018 05:19:20 PM UTC, comment #46:

Ok then, I honestly don't know if it's a serious warning or not that the GMP and MPFR header versions are older than the installed libraries. Octave does not use GMP or MPFR directly.

The message is saying that gfortran 4.9.2 was built against these older versions of GMP and MPFR. Does that mean anything for building the end-user's Fortran code? I don't know.

Let's just ignore that for now and try to configure again with LD_ALTEXEC not set, and with LD_LIBRARY_PATH and PKG_CONFIG_PATH set as you had them before.

I would like to see another config.log, even if configure succeeds, to verify that the big-endian bug symptom is in there.

Mike Miller <mtmiller>
Project Administrator
Sun 08 Jul 2018 04:21:28 PM UTC, comment #45:

"IMHO you should go back to using the default GCC configuration with the Solaris linker, unless you know how to make this work, more than specifying the LD_ALTEXEC variable."

OK, I have unset LD_ALTEXEC.

"In your original configuration, you had GMP 6.1.2, MPFR 3.1.5, and MPC 1.0.2."

I still do:

# pkgutil -i libgmp10
Solving needed dependencies ...
Solving dependency order ...
3 CURRENT packages:
CSWcommon-1.5,REV=2010.12.11
CSWlibgcc-s1-5.5.0,REV=2017.10.23
CSWlibgmp10-6.1.2,REV=2017.03.09

Nothing to do.
# pkgutil -i libmpfr6
Solving needed dependencies ...
Solving dependency order ...
4 CURRENT packages:
CSWcommon-1.5,REV=2010.12.11
CSWlibgcc-s1-5.5.0,REV=2017.10.23
CSWlibgmp10-6.1.2,REV=2017.03.09
CSWlibmpfr6-4.0.0,REV=2018.01.16

Nothing to do.
# pkgutil -i libmpc3
Solving needed dependencies ...
Solving dependency order ...
5 CURRENT packages:
CSWcommon-1.5,REV=2010.12.11
CSWlibgcc-s1-5.5.0,REV=2017.10.23
CSWlibgmp10-6.1.2,REV=2017.03.09
CSWlibmpc3-1.0.2,REV=2014.03.17
CSWlibmpfr4-3.1.5,REV=2016.11.28

Nothing to do.
#

"You should see if you can fix your packages so that GMP is 5.0.4 and MPFR is 3.1.2."

As far as I can see I have no other gmp anywhere, and GMP 6.1.2 is the only version offered on opencsw, so I don't know how I can accomplish this.

Similarly, opencsw has MPFR 3.1.5 and 4.0.0. I have both of these, but not 3.1.2. I don't know what I can do about that. Why is it asking for ancient versions of these libraries?

How do you get code fragments to show up inside their own little scrolling window in your posts?

Michele <michele31415>
Sun 08 Jul 2018 03:26:35 AM UTC, comment #44:

I see two major problems now with your current configuration.

First, the BLAS library error actually looks like the GNU gld linker isn't working correctly when compiling any simple test program.

IMHO you should go back to using the default GCC configuration with the Solaris linker, unless you know how to make this work, more than specifying the LD_ALTEXEC variable.

Here are a couple of examples from the latest config.log, showing that it fails to link any C++ or Fortran program.

The .map file is a Solaris linker file format, and it is being picked up when linking executables by GCC even when you are telling it to use the GNU linker.

The second problem is that you now have other library conflicts related to the downgrade from GCC 5 to GCC 4, or maybe specifically from gfortran 5 to gfortran 4. GMP, MPFR, and MPC are three math libraries that are required by gfortran. In your original configuration, you had GMP 6.1.2, MPFR 3.1.5, and MPC 1.0.2.

In the latest two config.log files since gfortran was downgraded to 4.9.2, I see the following warning messages show up when a Fortran test program is compiled with the '-v' option.

You should see if you can fix your packages so that GMP is 5.0.4 and MPFR is 3.1.2.

Mike Miller <mtmiller>
Project Administrator
Sat 07 Jul 2018 11:58:12 PM UTC, comment #43:

"I think we need the log file for the original error when you weren't trying to specify BLAS and LAPACK arguments."

OK, so:

# BLAS_LIBS=
# LAPACK_LIBS=
# export BLAS_LIBS
# export LAPACK_LIBS
# ./configure

config.log is here:
https://login.filesanywhere.com/fs/v.aspx?v=8c69638b5f676d76a1

Same blas/lapack error.

Michele <michele31415>
Sat 07 Jul 2018 09:29:35 PM UTC, comment #42:

Ok, the error in this config.log is that you are specifying a directory for --with-blas and --with-lapack, don't do that.

The right way to use those options is something like

I think we need the log file for the original error when you weren't trying to specify BLAS and LAPACK arguments. The reported error message may be the same but the cause has changed since you added those arguments.

Mike Miller <mtmiller>
Project Administrator
Sat 07 Jul 2018 09:07:44 PM UTC, comment #41:

The config.log for the latest ./configure (with the blas/lapack problem) is here:

https://login.filesanywhere.com/fs/v.aspx?v=8c69638b5f666dbeac6b

Michele <michele31415>
Sat 07 Jul 2018 07:28:54 PM UTC, comment #40:

Setting

# BLAS_LIBS=/opt/csw/lib
# LAPACK_LIBS=/opt/csw/lib

did not help. Nor did

# ./configure --with-blas=/opt/csw/lib --with-lapack=/opt/csw/lib

It still says

configure: error: BLAS and LAPACK libraries are required

This meessage come from here in configure:

if test $ax_blas_ok = no || test $ax_lapack_ok = no; then
as_fn_error $? "BLAS and LAPACK libraries are required" "$LINENO" 5
fi

This bit from the log may be relevant:

checking whether LSAME is called correctly from Fortran... no
checking whether ISAMAX is called correctly from Fortran... no
checking whether SDOT is called correctly from Fortran... no
checking whether DDOT is called correctly from Fortran... no
checking whether CDOTU is called correctly from Fortran... no
checking whether ZDOTU is called correctly from Fortran... no

as that is what appears to set $ax_blas_ok.

Why this is happening is unclear.

Michele <michele31415>
Sat 07 Jul 2018 07:10:03 PM UTC, comment #39:

> checking BLAS library integer size... 4
> configure: error: BLAS and LAPACK libraries are required


We need more context, like yet another config.log file. Having a BLAS integer size of 4 is not an error, but this is probably related to bug #53853 that I mentioned earlier.

Mike Miller <mtmiller>
Project Administrator
Sat 07 Jul 2018 07:00:58 PM UTC, comment #38:

I found a fix for the ld issue:

# LD_ALTEXEC=/opt/csw/bin/gld

I am now back to gcc 4.92, g++ 4.92 and gfortran 4.92

so I tried

./configure --libdir=/opt/csw/lib

This gave me a new error I wasn't getting before:
...
checking BLAS library integer size... 4
configure: error: BLAS and LAPACK libraries are required
#

But I do have those:

# cd /opt/csw/lib
# ls -l blas
-rwxr-xr-x 1 root root 321448 Jun 30 15:55 libblas.so
lrwxrwxrwx 1 root root 20 Jun 22 16:19 libgslcblas.so.0 -> libgslcblas.so.0.0.0
-rwxr-xr-x 1 root bin 234316 Nov 1 2013 libgslcblas.so.0.0.0
# ls -l lapack
-rwxr-xr-x 1 root root 13870064 Jun 30 12:14 liblapack.so
#

Michele <michele31415>
Sat 07 Jul 2018 06:49:42 PM UTC, comment #37:

That's a feature of how GCC is configured, not of our build system.

Some light googling found me https://stackoverflow.com/a/31521865/384593, which says

> gcc is compiled by default to use the Solaris linker. You can
> override this setting by using the LD_ALTEXEC environment variable:
>
> export LD_ALTEXEC=/opt/csw/gnu/ld


Mike Miller <mtmiller>
Project Administrator
Sat 07 Jul 2018 06:14:52 PM UTC, comment #36:

I saw that too. Thing is, I do have gld, and /opt/csw/bin is first in PATH:

# ls -l /opt/csw/bin/gld
-rwxr-xr-x 4 root bin 11189096 May 24 2015 /opt/csw/bin/gld
# which ld
/usr/ccs/bin/ld
# echo $PATH
/opt/csw/bin:/opt/csw/share:/opt/sfw/bin:/opt/csw/java/jdk1.8.0_171:/usr/sbin:/usr/bin:/usr/openwin/bin:/usr/X11/bin:/usr/local/bin:/usr/ccs/bin:/opt/csw/share/Adobe
#

What do I have to say to get it to use gld instead of /usr/ccs/bin/ld?

Michele <michele31415>
Sat 07 Jul 2018 04:32:28 PM UTC, comment #35:

Another thing I saw in the config log was that the linker was not GNU ld. It shouldn't make a differnce, but if I was just trying things I would see if having the entire build suite (gcc, g++, gfortran, and ld) were GNU tools.

Rik <rik5>
Project Administrator
Sat 07 Jul 2018 03:56:28 PM UTC, comment #34:

Well the easiest of all those options seems to be to remove gcc5 and reinstall gcc4. You did manage to create a working Solaris Octave 4.0 with the *4 tools before so it must be possible. It's just going to take a while.

Michele <michele31415>
Sat 07 Jul 2018 01:47:51 AM UTC, comment #33:

I don't know if any of us can help you debug this until you have a working compiler. I know that 4.9.2 worked better, but there was a definite linker conflict with multiple copies of the same shared libraries when you had GCC 4.9.2 but gfortran 5.5.0, so that was an unworkable configuration from the start.

Now with GCC 5.5.0, your compiler doesn't seem to be able to compile even a trivial C++11 program. If you want to fix that, you probably need some help from the Solaris porting/packaging experts as to why this doesn't work out of the box.

If it's possible to downgrade gfortran and GCC to 4.9.2, you could try that configuration instead.

Mike Miller <mtmiller>
Project Administrator
Sat 07 Jul 2018 12:03:48 AM UTC, comment #32:

"Can you try the same trivial program with"

# g++ -std=gnu++11 complex.cc
In file included from /opt/csw/include/c++/5.5.0/cmath:44:0,
from /opt/csw/include/c++/5.5.0/complex:44,
from complex.cc:2:
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:52:12: error: ‘std::float_t’ has not been declared
using std::float_t;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:53:12: error: ‘std::double_t’ has not been declared
using std::double_t;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:55:12: error: ‘std::fpclassify’ has not been declared
using std::fpclassify;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:56:12: error: ‘std::isfinite’ has not been declared
using std::isfinite;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:57:12: error: ‘std::isinf’ has not been declared
using std::isinf;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:58:12: error: ‘std::isnan’ has not been declared
using std::isnan;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:59:12: error: ‘std::isnormal’ has not been declared
using std::isnormal;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:60:12: error: ‘std::signbit’ has not been declared
using std::signbit;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:62:12: error: ‘std::isgreater’ has not been declared
using std::isgreater;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:63:12: error: ‘std::isgreaterequal’ has not been declared
using std::isgreaterequal;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:64:12: error: ‘std::isless’ has not been declared
using std::isless;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:65:12: error: ‘std::islessequal’ has not been declared
using std::islessequal;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:66:12: error: ‘std::islessgreater’ has not been declared
using std::islessgreater;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:67:12: error: ‘std::isunordered’ has not been declared
using std::isunordered;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:69:12: error: ‘std::acosh’ has not been declared
using std::acosh;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:70:12: error: ‘std::asinh’ has not been declared
using std::asinh;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:71:12: error: ‘std::atanh’ has not been declared
using std::atanh;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:72:12: error: ‘std::cbrt’ has not been declared
using std::cbrt;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:73:12: error: ‘std::copysign’ has not been declared
using std::copysign;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:74:12: error: ‘std::erf’ has not been declared
using std::erf;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:75:12: error: ‘std::erfc’ has not been declared
using std::erfc;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:76:12: error: ‘std::exp2’ has not been declared
using std::exp2;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:77:12: error: ‘std::expm1’ has not been declared
using std::expm1;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:78:12: error: ‘std::fdim’ has not been declared
using std::fdim;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:79:12: error: ‘std::fma’ has not been declared
using std::fma;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:80:12: error: ‘std::fmax’ has not been declared
using std::fmax;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:81:12: error: ‘std::fmin’ has not been declared
using std::fmin;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:82:12: error: ‘std::hypot’ has not been declared
using std::hypot;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:83:12: error: ‘std::ilogb’ has not been declared
using std::ilogb;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:84:12: error: ‘std::lgamma’ has not been declared
using std::lgamma;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:85:12: error: ‘std::llrint’ has not been declared
using std::llrint;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:86:12: error: ‘std::llround’ has not been declared
using std::llround;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:87:12: error: ‘std::log1p’ has not been declared
using std::log1p;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:88:12: error: ‘std::log2’ has not been declared
using std::log2;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:89:12: error: ‘std::logb’ has not been declared
using std::logb;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:90:12: error: ‘std::lrint’ has not been declared
using std::lrint;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:91:12: error: ‘std::lround’ has not been declared
using std::lround;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:92:12: error: ‘std::nan’ has not been declared
using std::nan;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:93:12: error: ‘std::nanf’ has not been declared
using std::nanf;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:94:12: error: ‘std::nanl’ has not been declared
using std::nanl;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:95:12: error: ‘std::nearbyint’ has not been declared
using std::nearbyint;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:96:12: error: ‘std::nextafter’ has not been declared
using std::nextafter;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:97:12: error: ‘std::nexttoward’ has not been declared
using std::nexttoward;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:98:12: error: ‘std::remainder’ has not been declared
using std::remainder;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:99:12: error: ‘std::remquo’ has not been declared
using std::remquo;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:100:12: error: ‘std::rint’ has not been declared
using std::rint;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:101:12: error: ‘std::round’ has not been declared
using std::round;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:102:12: error: ‘std::scalbln’ has not been declared
using std::scalbln;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:103:12: error: ‘std::scalbn’ has not been declared
using std::scalbn;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:104:12: error: ‘std::tgamma’ has not been declared
using std::tgamma;
^
/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/math.h:105:12: error: ‘std::trunc’ has not been declared
using std::trunc;
^
In file included from complex.cc:2:0:
/opt/csw/include/c++/5.5.0/complex: In function ‘typename __gnu_cxx::__promote<_Tp>::__type std::arg(_Tp)’:
/opt/csw/include/c++/5.5.0/complex:1832:14: error: ‘signbit’ is not a member of ‘std’
return std::signbit(__x) ? __type(3.1415926535897932384626433832795029L)
^
#

Michele <michele31415>
Fri 06 Jul 2018 09:34:29 PM UTC, comment #31:

My small mistake, the option '--disable-qt' should be '--without-qt'. I see in the summary that the Qt GUI is still trying to be built. But that small change won't make a difference on the errors with C++ compilation.

Rik <rik5>
Project Administrator
Fri 06 Jul 2018 09:05:33 PM UTC, comment #30:

Can you try the same trivial program with

Mike Miller <mtmiller>
Project Administrator
Fri 06 Jul 2018 09:02:53 PM UTC, comment #29:

"Your build log shows some serious C++ problems, you did not have those errors when you built with GCC 4.9.2, isn't that right?"

That is correct.

"There is a very serious configuration problem with the GCC 5.5.0 you installed if you can't compile a trivial program like this (this test program shows as failed in your config.log):"

Seems to work for me...

# more foo.cc
#include <complex>

int
main ()
{
std::complex<double> x;
x.real (1.0);
x.imag (2.0);
return 0;
}
# g++ foo.cc
# ./a.out
#

# more complex.cc
#include <iostream> // std::cout
#include <complex> // std::complex

int main ()
{
std::complex<double> first (2.0,2.0);
std::complex<float> second (first);

std::cout << second << '\n';

return 0;
}
# g++ complex.cc
# ./a.out
(2,2)
#

"Could you run the minimal configure again in this fashion"

Done. config.summary is here:
https://login.filesanywhere.com/fs/v.aspx?v=8c69638b5e6776aaa8ad

Michele <michele31415>
Fri 06 Jul 2018 07:10:46 PM UTC, comment #28:

Run either Mike's or my test program from the command line as they both will produce information about why g++ isn't finding some of its basic include files.

Rik <rik5>
Project Administrator
Fri 06 Jul 2018 06:56:16 PM UTC, comment #27:

@Michele: Thanks for trying all these test cases. Could you run the minimal configure again in this fashion

This will capture just what is printed to screen which is only a few pages worth of material to review. The config.log produced by configure is 5.1MB and includes every single test run, the results, etc., and is too difficult too parse.

Second, can you try compiling this simple program with g++?

I can compile and run this with

Rik <rik5>
Project Administrator
Fri 06 Jul 2018 06:53:30 PM UTC, comment #26:

Your build log shows some serious C++ problems, you did not have those errors when you built with GCC 4.9.2, isn't that right?

There is a very serious configuration problem with the GCC 5.5.0 you installed if you can't compile a trivial program like this (this test program shows as failed in your config.log):

You don't need to pass "FPICFLAG=-fPIC" now, the new configure that Rik provided you with is doing the right thing.

Mike Miller <mtmiller>
Project Administrator
Fri 06 Jul 2018 06:24:56 PM UTC, comment #25:

"There is no fix for that bug yet, but jwe has volunteered to work on a fix if he can get login access to a big-endian system to test on."

That is most generous. You are more than welcome to an account on my machine if you want. Just let me know.

Michele <michele31415>
Fri 06 Jul 2018 06:21:44 PM UTC, comment #24:

"Does it build?"

Using
gmake FPICFLAG=-fPIC LDFLAGS=/opt/csw/lib

I'm afraid not. More math errors. gmake log is here:

https://login.filesanywhere.com/fs/v.aspx?v=8c69638b5e5f6fa56d9d

"If not, can you try configuring a minimal CLI-only version"

This config completed with the usual bunch of not-found warnings. config.log is here:

https://login.filesanywhere.com/fs/v.aspx?v=8c69638b5e5f74acacae

gmake-ing that failed in the same way the previous one did - lots of stuff like this:

liboctave/numeric/lo-mappers.h:202:45: note: suggested alternative:
liboctave/numeric/lo-mappers.h:202:17: note: ‘octave::math::isfinite’
inline bool isfinite (float x) { return std::isfinite (x); }
^
liboctave/numeric/lo-mappers.h: In function ‘bool octave::math::isinf(double)’:
liboctave/numeric/lo-mappers.h:225:43: error: ‘isinf’ is not a member of ‘std’
inline bool isinf (double x) { return std::isinf (x); }
^
liboctave/numeric/lo-mappers.h:225:43: note: suggested alternative:
liboctave/numeric/lo-mappers.h:225:17: note: ‘octave::math::isinf’
inline bool isinf (double x) { return std::isinf (x); }
^
liboctave/numeric/lo-mappers.h: In function ‘bool octave::math::isinf(float)’:
liboctave/numeric/lo-mappers.h:226:42: error: ‘isinf’ is not a member of ‘std’
inline bool isinf (float x) { return std::isinf (x); }
^
liboctave/numeric/lo-mappers.h:226:42: note: suggested alternative:
liboctave/numeric/lo-mappers.h:226:17: note: ‘octave::math::isinf’
inline bool isinf (float x) { return std::isinf (x); }
^

Michele <michele31415>
Fri 06 Jul 2018 02:53:09 AM UTC, comment #23:

One additional problem is that you are hitting bug #53853 because your system is big-endian. There is no fix for that bug yet, but jwe has volunteered to work on a fix if he can get login access to a big-endian system to test on.

If you want to work around it, you can edit the Octave configure script and replace every instance of "ax_blas_integer_size=8" with "ax_blas_integer_size=4" (or gsed -i 's/ax_blas_integer_size=8/ax_blas_integer_size=4/' configure).

Mike Miller <mtmiller>
Project Administrator
Fri 06 Jul 2018 02:31:37 AM UTC, comment #22:

I agree, this looks like a better start than the first log. The compiler flags look correct, missing QScintilla is not a deal-breaker.

If Octave builds as you have it configured now, then Rik's fix to configure looks like it solved the original problem.

Mike Miller <mtmiller>
Project Administrator
Fri 06 Jul 2018 02:05:39 AM UTC, comment #21:

Not bad results. The FPICFLAG is set correctly, and I see that g++ and gcc are both at version 5.5.0 now.

Does it build?

If not, can you try configuring a minimal CLI-only version with

This would be the first thing to get working before moving on to the GUI, graphics, and external Java interface.

Rik <rik5>
Project Administrator
Fri 06 Jul 2018 12:38:28 AM UTC, comment #20:

OK, I downloaded that and ran

# pwd
/export/home/michele/octave-4.4.0x
# ./configure --libdir=/opt/csw/lib

and got this config.log:

https://login.filesanywhere.com/fs/v.aspx?v=8c69638b5d5e73ada9

It finished but with one game-ending warning:

configure: WARNING: QScintilla library not found; disabling built-in Qt GUI editor

even though I do have QScintilla:

# pwd
/opt/csw/lib
# ls -l cint
-rwxr-xr-x 1 root root 3792576 Jul 5 19:54 libqscintilla2.so
-rwxr-xr-x 1 root root 3792576 Jul 5 19:54 libqscintilla2.so.11
-rwxr-xr-x 1 root root 3792576 Jul 5 19:54 libqscintilla2.so.11.3
-rwxr-xr-x 1 root root 3792576 Jul 5 19:54 libqscintilla2.so.11.3.0
lrwxrwxrwx 1 root root 20 Jun 28 12:39 libscintilla.so -> libscintilla.so.2.26
lrwxrwxrwx 1 root root 20 Jun 28 12:39 libscintilla.so.2 -> libscintilla.so.2.26
-rwxr-xr-x 1 root bin 1885080 Jun 14 2011 libscintilla.so.2.26
#

What I don't have is a .pc file for QScintilla in pkgconfig/ even though I have loaded libscintilla_dev from opwncsw (https://www.opencsw.org/get-it/packages/)

I have also set:

#PATH=/opt/csw/bin:/opt/csw/share:/opt/sfw/bin:/opt/csw/java/jdk1.8.0_171:/usr/sbin:/usr/bin:/usr/openwin/bin:/usr/X11/bin:/usr/local/bin:/usr/ccs/bin:/opt/csw/share/Adobe
# LD_LIBRARY_PATH=/opt/csw/lib:/usr/local/lib:/opt/sfw/lib
# JAVA_HOME=/opt/csw/java/jdk1.8.0_171
# QT_LIBS=/opt/csw/lib
# PKG_CONFIG_PATH=/opt/csw/lib/pkgconfig:/usr/local/lib/pkgconfig:/opt/sfw/lib/pkgconfig:/usr/lib/pkgconfig

I have NOT set LDFLAGS or LIBS. If I set those, configure claims the gcc compiler doesn't work.

Michele <michele31415>
Thu 05 Jul 2018 11:54:48 PM UTC, comment #19:

@Michele: I made a tar.lz file of the latest stable distribution which you can download here (https://spideroak.com/storage/OVPXG4DJMRSXE33BNNPWC5LUN5PTEMJUG44DE/shared/1331845-1-4535/octave-4.4.0x.tar.lz?031f9b02bc13c7d5aa24d5b16addccab). The link is good for 3 days.

To test, download the file and then

Rik <rik5>
Project Administrator
Wed 04 Jul 2018 08:12:53 PM UTC, comment #18:

I'm pretty sure the change I have for configure.ac is correct so I pushed it here (http://hg.savannah.gnu.org/hgweb/octave/rev/5f9fa229cc8a). It works for me, but since I can't get further testing I decided to push it and see if it upsets the buildbots.

Rik <rik5>
Project Administrator
Wed 04 Jul 2018 07:10:55 PM UTC, comment #17:

Try compressing the config.log. The actual file size limit is much smaller than the one that Savannah suggests. Unfortunately when the size limit is surpassed there is no indication of any kind that the upload failed.

Rik <rik5>
Project Administrator
Wed 04 Jul 2018 07:08:13 PM UTC, comment #16:

"And no, the config.log is not attached."

I don't get it. I clicked on the "Attach files" button, clicked on the file in the file browser and it appeared next to the add button. It's not over the file size limit. In any case:

https://login.filesanywhere.com/fs/v.aspx?v=8c69638b5a5f74ae9b66

"the Solaris 'id' program is not POSIX-compatible."

There is another id in /usr/xpg5/bin/

# file /usr/bin/id
/usr/bin/id: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped
# ls -l /usr/xpg4/bin/id
-r-xr-xr-x 1 root bin 10288 Jul 6 2011 /usr/xpg4/bin/id
# which id
/usr/bin/id
# ls -l /usr/bin/id
-r-xr-xr-x 1 root bin 10288 Jul 6 2011 /usr/bin/id
# diff /usr/bin/id /usr/xpg4/bin/id
Binary files /usr/bin/id and /usr/xpg4/bin/id differ
#

Michele <michele31415>
Wed 04 Jul 2018 06:52:54 PM UTC, comment #15:

"in the previous config.log that you shared, gcc and g++ are both version 4.9.2, but gfortran is version 5.5.0. Not good,"

OK, then I will update gcc. The latest version available on opencdw is 5.5.0. (This will probably take a while, even on the M3000).

Michele <michele31415>
Wed 04 Jul 2018 05:55:15 PM UTC, comment #14:

I did just notice, though, that in the previous config.log that you shared, gcc and g++ are both version 4.9.2, but gfortran is version 5.5.0. Not good, I believe this may be one of the sources, or the primary cause, of the name conflict and multiple inclusion errors you are running into. Please make sure all gcc/g++/gfortran packages are the same version, preferably the highest version available.

Mike Miller <mtmiller>
Project Administrator
Wed 04 Jul 2018 05:44:32 PM UTC, comment #13:

JFTR, when I was testing Octave 4.0 on Solaris, the only workaround for the 'id: illegal option' error was to patch configure so that it called 'gid -u' and 'gid -g', the Solaris 'id' program is not POSIX-compatible. But that is only needed for figuring out the 'tar' command for making 'dist', not related to this error.

And no, the config.log is not attached.

Mike Miller <mtmiller>
Project Administrator
Wed 04 Jul 2018 04:24:21 PM UTC, comment #12:

"I made some changes and generated a new configure file which is attached to this bug report as configure.gz. Could you rename your existing configure, then gunzip configure.gz, then run ./configure as you normally would? It would be nice if you could capture the output of the configure run and upload it."

OK, I ran that but it didn't get very far:

# ./configure
checking for a BSD-compatible install... /opt/csw/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/csw/bin/gmkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
id: illegal option -- u
Usage: id [-ap] [user]
id: illegal option -- g
Usage: id [-ap] [user]
checking whether UID 'unknown' is supported by ustar format... ./configure: line 5775: test: unknown: integer expression expected
no
checking whether GID 'unknown' is supported by ustar format... ./configure: line 5785: test: unknown: integer expression expected
no
checking how to create a ustar tar archive... none
checking whether make supports nested variables... (cached) yes
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/export/home/michele/octave-4.4.0':
configure: error: C compiler cannot create executables
See `config.log' for more details

I have attached config.log. Hopefully it comes out this time.

Michele <michele31415>
Wed 04 Jul 2018 04:13:08 PM UTC, comment #11:

"Does something like this work?
gmake FPICFLAG=-fPIC LDFLAGS='-L/opt/csw/lib'"

Yes! It got me past that pesky libtool error.

(Recall:

ld: fatal: recording name conflict: file '/opt/csw/lib/libstdc++.so' and file '/usr/sfw/lib/libstdc++.so' provide identical dependency names: libstdc++.so.6 (possible multiple inclusion of the same file))

It went further but now it's stopping with something similar. This time it's looking at /usr/openwin/include/GL/ and /opt/csw/include/GL/

----------------------------------------------------------------

ld: warning: file /opt/csw/lib/libgomp.so: attempted multiple inclusion of file
GEN libinterp/dldfcn/__glpk__.oct
CXX libinterp/dldfcn/libinterp_dldfcn___init_fltk___la-__init_fltk__.lo
In file included from libinterp/dldfcn/__init_fltk__.cc:46:0:
/usr/openwin/include/X11/Xlib.h:38:0: warning: ignoring #pragma ident [-Wunknown-pragmas]
#pragma ident "@(#)Xlib.h 1.12 04/07/14 SMI"
^
In file included from libinterp/corefcn/oct-opengl.h:35:0,
from libinterp/dldfcn/__init_fltk__.cc:98:
/usr/openwin/include/GL/glu.h:6:0: warning: ignoring #pragma ident [-Wunknown-pragmas]
#pragma ident "@(#)glu.h 1.17 01/01/11 SMI"
^
In file included from libinterp/corefcn/oct-opengl.h:41:0,
from libinterp/dldfcn/__init_fltk__.cc:98:
/opt/csw/include/GL/glext.h:5103:96: error: ‘GLintptr’ has not been declared
typedef void (APIENTRYP PFNGLBINDBUFFERRANGEPROC) (GLenum target, GLuint index, GLuint buffer, GLintptr offset, GLsizeiptr size);
^
/opt/csw/include/GL/glext.h:5103:113: error: ‘GLsizeiptr’ has not been declared
typedef void (APIENTRYP PFNGLBINDBUFFERRANGEPROC) (GLenum target, GLuint index, GLuint buffer, GLintptr offset, GLsizeiptr size);
^
/opt/csw/include/GL/glext.h:5868:69: error: ‘GLintptr’ has not been declared
typedef GLvoid* (APIENTRYP PFNGLMAPBUFFERRANGEPROC) (GLenum target, GLintptr offset, GLsizeiptr length, GLbitfield access);
^
/opt/csw/include/GL/glext.h:5868:86: error: ‘GLsizeiptr’ has not been declared
typedef GLvoid* (APIENTRYP PFNGLMAPBUFFERRANGEPROC) (GLenum target, GLintptr offset, GLsizeiptr length, GLbitfield access);
^
/opt/csw/include/GL/glext.h:5869:74: error: ‘GLintptr’ has not been declared
typedef void (APIENTRYP PFNGLFLUSHMAPPEDBUFFERRANGEPROC) (GLenum target, GLintptr offset, GLsizeiptr length);
^
/opt/csw/include/GL/glext.h:5869:91: error: ‘GLsizeiptr’ has not been declared
typedef void (APIENTRYP PFNGLFLUSHMAPPEDBUFFERRANGEPROC) (GLenum target, GLintptr offset, GLsizeiptr length);
^
/opt/csw/include/GL/glext.h:5931:93: error: ‘GLintptr’ has not been declared
typedef void (APIENTRYP PFNGLCOPYBUFFERSUBDATAPROC) (GLenum readTarget, GLenum writeTarget, GLintptr readOffset, GLintptr writeOffset, GLsizeiptr size);
^
/opt/csw/include/GL/glext.h:5931:114: error: ‘GLintptr’ has not been declared
typedef void (APIENTRYP PFNGLCOPYBUFFERSUBDATAPROC) (GLenum readTarget, GLenum writeTarget, GLintptr readOffset, GLintptr writeOffset, GLsizeiptr size);
^
/opt/csw/include/GL/glext.h:5931:136: error: ‘GLsizeiptr’ has not been declared
typedef void (APIENTRYP PFNGLCOPYBUFFERSUBDATAPROC) (GLenum readTarget, GLenum writeTarget, GLintptr readOffset, GLintptr writeOffset, GLsizeiptr size);
^
In file included from libinterp/corefcn/oct-opengl.h:41:0,
from libinterp/dldfcn/__init_fltk__.cc:98:
/opt/csw/include/GL/glext.h:8429:79: error: ‘GLintptr’ has not been declared
typedef void (APIENTRYP PFNGLFLUSHMAPPEDBUFFERRANGEAPPLEPROC) (GLenum target, GLintptr offset, GLsizeiptr size);
^
/opt/csw/include/GL/glext.h:8429:96: error: ‘GLsizeiptr’ has not been declared
typedef void (APIENTRYP PFNGLFLUSHMAPPEDBUFFERRANGEAPPLEPROC) (GLenum target, GLintptr offset, GLsizeiptr size);
^
/opt/csw/include/GL/glext.h:8690:98: error: ‘GLintptr’ has not been declared
typedef void (APIENTRYP PFNGLBINDBUFFERRANGENVPROC) (GLenum target, GLuint index, GLuint buffer, GLintptr offset, GLsizeiptr size);
^
/opt/csw/include/GL/glext.h:8690:115: error: ‘GLsizeiptr’ has not been declared
typedef void (APIENTRYP PFNGLBINDBUFFERRANGENVPROC) (GLenum target, GLuint index, GLuint buffer, GLintptr offset, GLsizeiptr size);
^
/opt/csw/include/GL/glext.h:8691:99: error: ‘GLintptr’ has not been declared
typedef void (APIENTRYP PFNGLBINDBUFFEROFFSETNVPROC) (GLenum target, GLuint index, GLuint buffer, GLintptr offset);
^
/opt/csw/include/GL/glext.h:8709:18: error: typedef ‘GLintptr’ is initialized (use decltype instead)
typedef GLintptr (APIENTRYP PFNGLGETUNIFORMOFFSETEXTPROC) (GLuint program, GLint location);
^
/opt/csw/include/GL/glext.h:8709:29: error: ‘PFNGLGETUNIFORMOFFSETEXTPROC’ was not declared in this scope
typedef GLintptr (APIENTRYP PFNGLGETUNIFORMOFFSETEXTPROC) (GLuint program, GLint location);
^
/opt/csw/include/GL/glext.h:8779:99: error: ‘GLintptr’ has not been declared
typedef void (APIENTRYP PFNGLBINDBUFFERRANGEEXTPROC) (GLenum target, GLuint index, GLuint buffer, GLintptr offset, GLsizeiptr size);
^
/opt/csw/include/GL/glext.h:8779:116: error: ‘GLsizeiptr’ has not been declared
typedef void (APIENTRYP PFNGLBINDBUFFERRANGEEXTPROC) (GLenum target, GLuint index, GLuint buffer, GLintptr offset, GLsizeiptr size);
^
/opt/csw/include/GL/glext.h:8780:100: error: ‘GLintptr’ has not been declared
typedef void (APIENTRYP PFNGLBINDBUFFEROFFSETEXTPROC) (GLenum target, GLuint index, GLuint buffer, GLintptr offset);
^
/opt/csw/include/GL/glext.h:9132:70: error: ‘GLsizeiptr’ has not been declared
typedef void (APIENTRYP PFNGLNAMEDBUFFERDATAEXTPROC) (GLuint buffer, GLsizeiptr size, const GLvoid *data, GLenum usage);
^
/opt/csw/include/GL/glext.h:9133:73: error: ‘GLintptr’ has not been declared
typedef void (APIENTRYP PFNGLNAMEDBUFFERSUBDATAEXTPROC) (GLuint buffer, GLintptr offset, GLsizeiptr size, const GLvoid *data);
^
/opt/csw/include/GL/glext.h:9133:90: error: ‘GLsizeiptr’ has not been declared
typedef void (APIENTRYP PFNGLNAMEDBUFFERSUBDATAEXTPROC) (GLuint buffer, GLintptr offset, GLsizeiptr size, const GLvoid *data);
^
/opt/csw/include/GL/glext.h:9138:76: error: ‘GLintptr’ has not been declared
typedef void (APIENTRYP PFNGLGETNAMEDBUFFERSUBDATAEXTPROC) (GLuint buffer, GLintptr offset, GLsizeiptr size, GLvoid *data);
^
/opt/csw/include/GL/glext.h:9138:93: error: ‘GLsizeiptr’ has not been declared
typedef void (APIENTRYP PFNGLGETNAMEDBUFFERSUBDATAEXTPROC) (GLuint buffer, GLintptr offset, GLsizeiptr size, GLvoid *data);
^
/opt/csw/include/GL/glext.h:9438:106: error: ‘GLsizeiptr’ has not been declared
typedef void (APIENTRYP PFNGLBUFFERADDRESSRANGENVPROC) (GLenum pname, GLuint index, GLuint64EXT address, GLsizeiptr length);
^
gmake[2]: *** [Makefile:18606: libinterp/dldfcn/libinterp_dldfcn___init_fltk___la-__init_fltk__.lo] Error 1
gmake[2]: Leaving directory '/export/home/michele/octave-4.4.0'
gmake[1]: *** [Makefile:26469: all-recursive] Error 1
gmake[1]: Leaving directory '/export/home/michele/octave-4.4.0'
gmake: *** [Makefile:10185: all] Error 2
#

Michele <michele31415>
Tue 03 Jul 2018 09:52:29 PM UTC, comment #10:

@Michele: I made some changes and generated a new configure file which is attached to this bug report as configure.gz. Could you rename your existing configure, then gunzip configure.gz, then run ./configure as you normally would? It would be nice if you could capture the output of the configure run and upload it. For example, with syntax like so

Inside myconf.log I expect to see

if this has worked.

(file #44503)

Rik <rik5>
Project Administrator
Tue 03 Jul 2018 09:44:28 PM UTC, comment #9:

Regarding the inability to build in comment #8, I think LDFLAGS is incorrect. You need '-L' to tell ld that the argument after it is a directory to search.

Does something like this work?

Rik <rik5>
Project Administrator
Tue 03 Jul 2018 12:38:01 AM UTC, comment #8:

I discovered this:

# ls -l std
-rw-r--r-- 1 root bin 12246176 Nov 4 2014 libstdc++.a
-rwxr-xr-x 1 root bin 959 Nov 4 2014 libstdc++.la
lrwxrwxrwx 1 root root 19 Jun 25 11:13 libstdc++.so -> libstdc++.so.6.0.20
lrwxrwxrwx 1 root root 19 Jun 22 16:19 libstdc++.so.6 -> libstdc++.so.6.0.21
-rw-r--r-- 1 root bin 2300 Nov 4 2014 libstdc++.so.6.0.20-gdb.py
-rwxr-xr-x 1 root bin 11689172 Oct 13 2017 libstdc++.so.6.0.21

So apparently libstdc++.so was pointing to something not there anymore. Perhaps I'm being stupid again but I did this:

# ln -s libstdc++.so.6.0.21 libstdc++.so
#

But it's still not happy:

# gmake FPICFLAG=-fPIC LDFLAGS=/opt/csw/lib
preserving existing HG-ID file
GEN libinterp/builtin-defun-decls.h
gmake all-recursive
gmake[1]: Entering directory '/export/home/michele/octave-4.4.0'
preserving existing HG-ID file
Making all in libgnu
gmake[2]: Entering directory '/export/home/michele/octave-4.4.0/libgnu'
gmake all-recursive
gmake[3]: Entering directory '/export/home/michele/octave-4.4.0/libgnu'
gmake[4]: Entering directory '/export/home/michele/octave-4.4.0/libgnu'
gmake[4]: Nothing to be done for 'all-am'.
gmake[4]: Leaving directory '/export/home/michele/octave-4.4.0/libgnu'
gmake[3]: Leaving directory '/export/home/michele/octave-4.4.0/libgnu'
gmake[2]: Leaving directory '/export/home/michele/octave-4.4.0/libgnu'
gmake[2]: Entering directory '/export/home/michele/octave-4.4.0'
preserving existing HG-ID file
GEN libinterp/builtin-defun-decls.h
CXXLD liboctave/liboctave.la
ld: warning: file /opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/../../../libgomp.so: linked to /opt/csw/lib/libgomp.so: attempted multiple inclusion of file
CXXLD libinterp/liboctinterp.la
libtool: warning: '/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.9.2/../../../libstdc++.la' seems to be moved
libtool: warning: '/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.9.2/../../../libgomp.la' seems to be moved
libtool: warning: '/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/../../../libgfortran.la' seems to be moved
libtool: warning: '/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/../../../libstdc++.la' seems to be moved
libtool: warning: '/opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/../../../libgomp.la' seems to be moved
ld: fatal: recording name conflict: file '/opt/csw/lib/libstdc++.so' and file '/usr/sfw/lib/libstdc++.so' provide identical dependency names: libstdc++.so.6 (possible multiple inclusion of the same file)
ld: warning: file /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.9.2/../../../libgomp.so: linked to /opt/csw/lib/libgomp.so: attempted multiple inclusion of file
ld: fatal: file processing errors. No output written to libinterp/.libs/liboctinterp.so.5.0.0
gmake[2]: *** [Makefile:11828: libinterp/liboctinterp.la] Error 1
gmake[2]: Leaving directory '/export/home/michele/octave-4.4.0'
gmake[1]: *** [Makefile:26469: all-recursive] Error 1
gmake[1]: Leaving directory '/export/home/michele/octave-4.4.0'
gmake: *** [Makefile:10185: all] Error 2
#

Michele <michele31415>
Tue 03 Jul 2018 12:31:13 AM UTC, comment #7:

What does this command show?

It is possible that the file is a symbolic link, so it shows up with

, but it points to a non-existent file.

Rik <rik5>
Project Administrator
Tue 03 Jul 2018 12:20:44 AM UTC, comment #6:

I should add that I do already have libstdc++.

# pkgutil -i libstdc++6
Solving needed dependencies ...
Solving dependency order ...
3 CURRENT packages:
CSWcommon-1.5,REV=2010.12.11
CSWlibgcc-s1-5.5.0,REV=2017.10.23
CSWlibstdc++6-5.5.0,REV=2017.10.23

Nothing to do.
# cd /opt/csw/lib
# ls std
libstdc++.a libstdc++.so.6
libstdc++.la libstdc++.so.6.0.20-gdb.py
libstdc++.so libstdc++.so.6.0.21
#

Michele <michele31415>
Tue 03 Jul 2018 12:17:53 AM UTC, comment #5:

Using

gmake FPICFLAG=-fPIC LDFLAGS=/opt/csw/lib

got rid of the KPIC error. All the F77 lines completed OK.

We've gone further but now it's stopping with:

...
CXX liboctave/util/liboctave_util_libutil_la-lo-regexp.lo
CXX liboctave/util/liboctave_util_libutil_la-lo-utils.lo
CXX liboctave/util/liboctave_util_libutil_la-quit.lo
CXX liboctave/util/liboctave_util_libutil_la-oct-base64.lo
liboctave/util/oct-base64.cc: In function ‘Array<double> octave::base64_decode(const string&)’:
liboctave/util/oct-base64.cc:85:55: warning: cast from ‘char*’ to ‘double*’ increases required alignment of target type [-Wcast-align]
double dout = reinterpret_cast<double > (out);
^
CXX liboctave/util/liboctave_util_libutil_la-oct-glob.lo
CXX liboctave/util/liboctave_util_libutil_la-oct-inttypes.lo
CXX liboctave/util/liboctave_util_libutil_la-oct-mutex.lo
CXX liboctave/util/liboctave_util_libutil_la-oct-shlib.lo
CXX liboctave/util/liboctave_util_libutil_la-oct-sparse.lo
CXX liboctave/util/liboctave_util_libutil_la-oct-string.lo
CXX liboctave/util/liboctave_util_libutil_la-pathsearch.lo
CXX liboctave/util/liboctave_util_libutil_la-singleton-cleanup.lo
CXX liboctave/util/liboctave_util_libutil_la-sparse-sort.lo
CXX liboctave/util/liboctave_util_libutil_la-sparse-util.lo
CXX liboctave/util/liboctave_util_libutil_la-str-vec.lo
CXX liboctave/util/liboctave_util_libutil_la-unwind-prot.lo
CXX liboctave/util/liboctave_util_libutil_la-url-transfer.lo
F77 liboctave/util/liboctave_util_libutil_la-d1mach.lo
F77 liboctave/util/liboctave_util_libutil_la-i1mach.lo
F77 liboctave/util/liboctave_util_libutil_la-r1mach.lo
CC liboctave/util/liboctave_util_libutil_la-f2c-main.lo
CC liboctave/util/liboctave_util_libutil_la-lo-cutils.lo
CC liboctave/util/liboctave_util_libutil_la-blaswrap.lo
CC liboctave/util/liboctave_util_libutil_la-cquit.lo
CC liboctave/util/liboctave_util_libutil_la-f77-fcn.lo
CC liboctave/util/liboctave_util_libutil_la-lo-error.lo
CC liboctave/util/liboctave_util_libutil_la-oct-rl-edit.lo
CC liboctave/util/liboctave_util_libutil_la-oct-rl-hist.lo
CXXLD liboctave/util/libutil.la
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-areadlink-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-async-system-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-base64-wrappers.lo CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-canonicalize-file-name-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-dirent-wrappers.lo CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-fcntl-wrappers.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-filepos-wrappers.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-fpucw-wrappers.lo
liboctave/wrappers/fpucw-wrappers.c: In function ‘octave_end_long_double_rounding’:
liboctave/wrappers/fpucw-wrappers.c:70:47: warning: unused parameter ‘oldcw’ [-Wunused-parameter]
octave_end_long_double_rounding (unsigned int oldcw)
^
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-gen-tempname-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-getopt-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-glob-wrappers.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-hash-wrappers.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-localcharset-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-math-wrappers.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-mkostemp-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-nanosleep-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-nproc-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-octave-popen2.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-putenv-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-set-program-name-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-signal-wrappers.loliboctave/wrappers/signal-wrappers.c: In function ‘print_sigset’:
liboctave/wrappers/signal-wrappers.c:737:20: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘pthread_t’ [-Wformat=]
strsignal (sig));
^
liboctave/wrappers/signal-wrappers.c:742:5: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘pthread_t’ [-Wformat=]
fprintf (of, "%ld: %s<empty signal set>\n", pthread_self (), prefix);
^
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-stat-wrappers.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-strdup-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-strftime-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-strmode-wrapper.lo CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-strptime-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-time-wrappers.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-tmpfile-wrapper.lo CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-uname-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-uniconv-wrappers.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-unistd-wrappers.lo CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-unsetenv-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-vasprintf-wrapper.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-wait-for-input.lo
CC liboctave/wrappers/liboctave_wrappers_libwrappers_la-wait-wrappers.lo
CCLD liboctave/wrappers/libwrappers.la
CXXLD liboctave/liboctave.la
g++: error: /opt/csw/lib/libstdc++.so: No such file or directory
gmake[2]: *** [Makefile:13291: liboctave/liboctave.la] Error 1
gmake[2]: Leaving directory '/export/home/michele/octave-4.4.0'
gmake[1]: *** [Makefile:26469: all-recursive] Error 1
gmake[1]: Leaving directory '/export/home/michele/octave-4.4.0'
gmake: *** [Makefile:10185: all] Error 2
#

Michele <michele31415>
Mon 02 Jul 2018 09:25:55 PM UTC, comment #4:

Confirmed that configure.ac sets the FPICFLAG before calling AC_PROG_F77. That is definitely a problem.

Rik <rik5>
Project Administrator
Mon 02 Jul 2018 09:22:29 PM UTC, comment #3:

Adding jwe and Michele to the bug report.

Rik <rik5>
Project Administrator
Mon 02 Jul 2018 09:20:12 PM UTC, comment #2:

Yeah, jwe is looking at this. The problem is the relative ordering of the AC_PROG_F77 macro being called now after the ac_cv_f77_compiler_gnu is used in this section. It looks like it was broken before 4.2.0 was released but we don't get a lot of testing on platforms where this logic is exercised.

Mike Miller <mtmiller>
Project Administrator
Mon 02 Jul 2018 09:18:21 PM UTC, comment #1:

The logic in configure.ac is shown below

Maybe have the original report run './configure -C' and then take a look at config.cache? On my computer, I have

Rik <rik5>
Project Administrator
Mon 02 Jul 2018 08:47:17 PM UTC, original submission:

On Solaris Octave's configure script sets the FPICFLAG variable (the Fortran compiler option to enable PIC) to '-KPIC' even when F77 is configured as GNU gfortran. This should be '-fPIC' when the compiler is GNU.

Mike Miller <mtmiller>
Project Administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #44545:  abs.diff added by mtmiller (3KiB - text/x-patch)
file #44503:  configure.gz added by rik5 (360KiB - application/gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by michele31415 (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-07-13 mtmiller Attached File- => Added abs.diff, #44545
    2018-07-06 rik5 Summaryconfigure sets FPICFLAG to '-KPIC' on Solaris even with F77='gfortran' => problems building Octave on Solaris
    2018-07-03 rik5 StatusNone => Confirmed
    2018-07-03 rik5 Attached File- => Added configure.gz, #44503
    2018-07-02 rik5 Carbon-Copy- => Added jwe
        Carbon-Copy- => Added michele

    Back to the top


    Powered by Savane 3.3