bugGNU Octave - Bugs: bug #43243, Failure building gui - fixable by...

 
 

bug #43243: Failure building gui - fixable by commenting out pointless line of libgnu/stdio.h

Submitter:  None
Submitted:  Wed 17 Sep 2014 09:28:35 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Duplicate Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  3.8.2
Operating System:  Mac OS Fixed Release:  None
Planned Release:  None

Discussion locked!

Jump to the original submission

Fri 19 Sep 2014 05:03:09 AM UTC, comment #8: 

I'm locking this discussion, please move to the mailing list.
 

Carlo de Falco <cdf>
Group Member
Thu 18 Sep 2014 06:28:44 PM UTC, comment #7: 

I haven't tried to implement the other fix because a) I'm not even sure how to, and b) the other fix is for a problem building with compilers other than gcc; the problem I'm having is for building with gcc. Not the same bug!

I literally mean gnu gcc 4.9.

And i am not referring to the apple developer program I'm referring to the notes about the binary bundle that are littered all over the octave documentation and next to all the download links for it.

Anonymous
Thu 18 Sep 2014 03:14:09 PM UTC, comment #6: 

  > the binary bundle download comes complete with a message to not use it


If you refer to the message about the code not being by
a registered apple developer, the reason for that is here:

 https://developer.apple.com/programs/mac/

signing the app requires joining a developer program,
which costs money, if you would like to contribute the
$99 required for me to join the program for one year, the app
bundle for 3.8.2 will come without that message.

Carlo de Falco <cdf>
Group Member
Thu 18 Sep 2014 02:45:47 PM UTC, comment #5: 


> Building octave 3.8.3 using gcc


Do you literally mean gcc, or Apple's frontend to llvm? They behave
quite differently. As I understand it, homebrew cannot use a real gcc,
not without much difficulty, difficulties as the one you're
experiencing. In my experience, Apple deliberately makes it hard to
use a real gcc, but perhaps I am mistaken and too stupid for Apple, or
too stupid to understand your bug report.

> Both bugs are problems created by libgnu/stdio.h.
>
> They are, however, different problems created by different parts of
> stdio.h, which require different changes to solve.


I am not convinced this is the case. You appear to be experiencing
another symptom of the same problem. The error message says,


 ../libgnu/stdio.h:1034:1: error: conflicting declaration of 'char*
 gets(char*)' with 'C++' linkage


But as the C++ standard says, uner C linkage the namespace is to be
ignored for the resulting symbol name. There would be no conflicting
declaration of the gets symbol if it were under the gnulib namespace
as it's supposed to be.

Please confirm that despite applying the fix from bug #43171, you
still observe trouble on Mac OS X.

At any rate, your suggested fix obviously cannot be implemented as-is,
as the first line of the file you're atttempting to patch reads,


/* DO NOT EDIT! GENERATED AUTOMATICALLY! */


If gnulib needs to be patched, this patch must to be applied deeper to
the original gnulib sources, not the auto-generated output.

> This is becoming ridiculous.


You may find a better audience for your frustration in the Octave
maintainers' list <maintainers@octave.org>. Let's keep the discussion
here pertinent to the problem at hand.

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Thu 18 Sep 2014 09:46:20 AM UTC, comment #4: 

I'm suggesting that one of the source files included with octave, and required to build it, contains an error that causes it to not build.  I understood that the libgnu folder in the octave source tarball comes from the octave maintainers and is intended to "fix" the standard headers.

While it is similar to the error in 43171, it's not the same --- different problem of the same type coming from the same header.

Is this really that hard to understand? I posted an error log-compare it to 43171.

This is becoming ridiculous. Octave on the Mac is a mess. The package manager maintainers can't get it building consistently, the instructions on the wiki are years out of date, the binary bundle download comes complete with a message to not use it, and the last few octave releases have selected as defaults options that have been known to create fatal bugs for, again, more than a year.

I have a pretty strong suspicion about what's going on with the blases, based on some error reports that others have posted, but I want to confirm it first.

Anyway, I tried to help you. Octaves got a pretty massive maintenance issue on a popular os. You don't seem to want to be helped.

Oh, and ps--a couple of the reports that you've closed tonight shortly after I posted them, were posted here after irc discussion about them with another of your maintainers, who encouraged the posts.

Anonymous
Thu 18 Sep 2014 09:33:41 AM UTC, comment #3: 

if you are suggesting libgnu/stdio.h should be changed,
then you should discuss it with the gnulib maintainers,
as that file is part of gnulib.

If you think the way Octave includes and uses
libgnu/stdio.h is wrong, then this tracker is
the correct place to discuss it, but in that
case the topic you has been already brought up in
#43171

Carlo de Falco <cdf>
Group Member
Thu 18 Sep 2014 08:56:53 AM UTC, comment #2: 

No.

Both bugs are problems created by libgnu/stdio.h.

They are, however, different problems created by different parts of stdio.h, which require different changes to solve.

Anonymous
Thu 18 Sep 2014 08:54:49 AM UTC, comment #1: 

this seems to be a duplicate of #43171

Carlo de Falco <cdf>
Group Member
Wed 17 Sep 2014 09:28:35 PM UTC, original submission:  

Building octave 3.8.3 using gcc with the gui enabled on a homebrew mac, there's an error emitted that terminates the build of the gui:

In file included from /usr/local/Cellar/gcc/4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/include/c++/cstdlib:72:0,
                 from /usr/local/Cellar/gcc/4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/include/c++/bits/stl_algo.h:59,
                 from /usr/local/Cellar/gcc/4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/include/c++/algorithm:62,
                 from /usr/local/Cellar/qt/4.8.6/include/QtCore/qglobal.h:68,
                 from /usr/local/Cellar/qt/4.8.6/include/QtCore/qnamespace.h:45,
                 from /usr/local/Cellar/qt/4.8.6/include/QtCore/qobjectdefs.h:45,
                 from /usr/local/Cellar/qt/4.8.6/include/QtCore/qobject.h:47,
                 from /usr/local/include/Qsci/qscilexeroctave.h:33,
                 from src/m-editor/file-editor-tab.cc:31:
../libgnu/stdio.h:1034:1: error: conflicting declaration of 'char* gets(char*)' with 'C++' linkage
 _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");


The problem is fixed simply by commenting out that line of libgnu/stdio.h

While I'm at it, here's a configure line that successfully builds octave using the homebrew install of gcc 4.9:

./configure CC=/usr/local/bin/gcc-4.9 CXX=/usr/local/bin/g++-4.9 CFLAGS="-I/usr/local/include -Ofast -m64 -march=native -mtune=native" CPPFLAGS="-I/usr/local/include" F77=/usr/local/bin/gfortran-4.9 FFLAGS="-I/usr/local/include -Ofast -m64 -march=native -mtune=native" LDFLAGS="-L/usr/local/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1 -L/usr/local/lib" FLIBS="-lgfortran -lquadmath -lm" --with-framework-carbon --without-x LLVM_CONFIG=/usr/local/bin/llvm-config-3.5

Anonymous

 

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

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by cdf (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

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

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-09-19 cdf Discussion LockNone Locked
    2014-09-18 cdf Open/ClosedOpen Closed
    2014-09-18 cdf StatusNone Duplicate

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code