octave-devel @3.4.3 build failure in Mac OSX 10.8

[vic@…]

All the prerequisites for octave-devel are compiled in my MacPorts system, but octave-devel will not compile. It fails in the build stage with the first error indication

:info:build display.cc:73:46: error: 'CGDisplayBitsPerPixel' was not declared in this scope
:info:build make[3]: *** [liboctinterp_la-display.lo] Error 1

The suggested Xcode fixes

sudo port install octave-devel configure.compiler=llvm-gcc-4.2

and

sudo port install apple-gcc42
sudo port install octave-devel configure.compiler=apple-gcc-4.2 configure.cxx=g++-apple-4.2

do not help. They never make it past the configure stage.

This is a Mac OSX 10.8 problem. I had no trouble building octave-devel @3.4.3 under OSX 10.7. However my McPorts system has been completely reinstalled under OSX 10.8. I now have 168 active ports. The only ports I have not been able to build are fltk-devel @1.3.x-r9327 and octave-devel @3.4.3.

I am attaching the main log for my octave-devel build attempt.

[onurdomanic@…]

Cc Me!

[bobm.dsp@…]

Cc Me!

[derekathomas@…]

Cc Me!

[mechgyver@…]

Cc Me!

[benjf5+macports@…]

Cc Me!

[dwb@…]

Cc Me!

[bpabbott@…]

Adding the block below to the port file will alleviate the CGDisplayBitsPerPixel error.

95	platform darwin 12 {
96	    # 10.7 requires an extra patch; this patch will break the build on
97	    # 10.6 and prior, so apply it only under 10.7.
98	    patchfiles-append patch-src-display.cc.diff
99	}

[onurdomanic@…]

I've added the block and the CGDisplayBitsPerPixel error disappears as you say, but now another error breaks the build:

:info:build sed: RE error: illegal byte sequence

I've attached the related log file to the ticket #30737.

[vic@…]

Cc Me!

[benjf5+macports@…]

Replying to onurdomanic@…:

I've added the block and the CGDisplayBitsPerPixel error disappears as you say, but now another error breaks the build:

:info:build sed: RE error: illegal byte sequence

I've attached the related log file to the ticket #30737.

The sed error seems to have come from changes Apple made to their sed; the fix that I've seen in a few places (and which worked for me building from Octave's development sources) was to first unset the LANG variable before building. (Homebrew has run into the same problem, see here: ​https://github.com/mxcl/homebrew/pull/13787)

[onurdomanic@…]

Replying to benjf5+macports@…:

Replying to onurdomanic@…:

I've added the block and the CGDisplayBitsPerPixel error disappears as you say, but now another error breaks the build:

:info:build sed: RE error: illegal byte sequence

I've attached the related log file to the ticket #30737.

The sed error seems to have come from changes Apple made to their sed; the fix that I've seen in a few places (and which worked for me building from Octave's development sources) was to first unset the LANG variable before building. (Homebrew has run into the same problem, see here: ​https://github.com/mxcl/homebrew/pull/13787)

I first tried unsetting LANG, then tried setting it to "C", and lastly unsetting LC_ALL too, but couldn't get a successful build yet. Still getting the same error:(

[benjf5+macports@…]

Replying to onurdomanic@…:

Replying to benjf5+macports@…:

Replying to onurdomanic@…:

I've added the block and the CGDisplayBitsPerPixel error disappears as you say, but now another error breaks the build:

:info:build sed: RE error: illegal byte sequence

I've attached the related log file to the ticket #30737.

The sed error seems to have come from changes Apple made to their sed; the fix that I've seen in a few places (and which worked for me building from Octave's development sources) was to first unset the LANG variable before building. (Homebrew has run into the same problem, see here: ​https://github.com/mxcl/homebrew/pull/13787)

I first tried unsetting LANG, then tried setting it to "C", and lastly unsetting LC_ALL too, but couldn't get a successful build yet. Still getting the same error:(

Do you have any of the LC_* variables set? They may contribute to the problem, if sed decides for some reason to ignore LC_ALL. (Lastly, did you do a fresh install of Mountain Lion, or was yours an upgrade from Lion? IIRC, there were some problems with Lion upgrades—Lion used the LC_ variables and Mountain Lion doesn't, but didn't remove them, or something like that.) Try setting LC_ALL to C and see if that fixes it?

[vic@…]

Mine was an upgrade from Lion. In so far as having any LC_* variables set, I don't know what you are talking about. And I don't know how to set LC_ALL to C. I was just trying to reinstall the math/octave-devel port on Mountain Lion. I was able to reinstall just about everything else I wanted --- aquaterm, ghostscript, gnuplot, etc.

Sorry I can't be of more help.

• Vic Norton

[miguelbarao (MB)]

Cc Me!

[AlonzoQuixote@…]

Cc Me!

[bhadder@…]

Cc Me!

[vjarao]

There all, this is great effort to help with open sources. However, there are too many issues to be solved. I had tried everything. I even opened a ticket that was tagged as duplicated when the issues was similar but not the same. Nevertheless, I applause the effort. I spent 5 days in a row to solve issues with either octave and octave-revel. I give up! All the best.

[kitchen.andy@…]

I've successfully compiled the latest octave (3.6.2) on mountain lion using a modified octave-devel port. It is attached. watch out though there are make check failures.

[kitchen.andy@…]

Cc Me!

[vjarao]

Cc Me!

[vjarao]

Dear kitchen.andy@… I am too newbie to understand how you did it. I am just a mac user. Could you please provide an easier explanation about how you installed octave-devel on Mountain Lion? I went to the attachment you provided and honestly that was sort of an extraterrestrial language for me.

Thanks

[kitchen.andy@…]

Replying to vjarao@…:

Dear kitchen.andy@… I am too newbie to understand how you did it. I am just a mac user. Could you please provide an easier explanation about how you installed octave-devel on Mountain Lion? I went to the attachment you provided and honestly that was sort of an extraterrestrial language for me.

Thanks

Hi vjarao,

It's probably best if you just wait until this port is updated in macports then you can just install it the normal way.

You need to create a local port repository and copy the portfile there, instructions are here:

​http://guide.macports.org/chunked/development.local-repositories.html

I'm going overseas soon, so I won't be able to help you in the next week or so, but if you really have trouble and really need octave send me a mail message and I'll try and get back to you when I get back from overseas.

[g5pw (Aljaž Srebrnič)]

Hello! i got the portfile to build on my machine, I'll just take a closer look and maybe ping the maintainer, and then commit it in the main tree.

[g5pw (Aljaž Srebrnič)]

Cc Me!

[kitchen.andy@…]

Replying to g5pw@…:

Hello! i got the portfile to build on my machine, I'll just take a closer look and maybe ping the maintainer, and then commit it in the main tree.

Getting in touch with the maintainer would be good, because I have also fixed a bunch of segfaults when octave is compiled with accelerate, but I'm not sure my fix is the best way of doing it.

I'll try and do it when I get back from my holiday.

[vjarao]

thank you everyone for making octave available. Fortunately I do not have rush. I am just anxious to have octave as my Maltab license (access) is going away soon. Thanks again.

[michaelld (Michael Dickens)]

I have a few items on my queue still, but this port is getting closer to being at the top. That said, if another maintainer wants to test, tweak, and check in an update to octave-devel, be my guest; add yourself as a co-maintainer even.

[g5pw (Aljaž Srebrnič)]

Replying to vjarao@…:

thank you everyone for making octave available. Fortunately I do not have rush. I am just anxious to have octave as my Maltab license (access) is going away soon. Thanks again.

Hang in there, man ;) Me or the maintainer will fix this during this week!

[vic@…]

Replying to kitchen.andy@…:

I've successfully compiled the latest octave (3.6.2) on mountain lion using a modified octave-devel port. It is attached. watch out though there are make check failures.

It certainly will be nice to have a current version of Octave on MacPorts. "Octave-devel" has been stuck at 3.4.3 forever, and "octave" is at 3.2.4. As far as I know neither of these can be compiled under Mountain Lion.

[kitchen.andy@…]

Replying to michaelld@…:

I have a few items on my queue still, but this port is getting closer to being at the top. That said, if another maintainer wants to test, tweak, and check in an update to octave-devel, be my guest; add yourself as a co-maintainer even.

Hi michaelld, I've already done this and attached the updated port, my request for commit access is still pending, until then I just can't commit the new port. I'll add myself as comaintainer once I get commit access.

To get Accelerate to work properly I had to add FFLAGS="-ff2c" to the configure environment, (this change isn't attached) for some reason the new version of Octave doesn't like dotwrp i.e. even though it seems to configure just fine, -ldotwrp just doesn't appear in some of the build commands and dot'ing complex vectors segfaults. I had a quick look at configure.ac and there seems to be some hacky sed magic going on with the BLAS link arguments.

Regards

AK

[g5pw (Aljaž Srebrnič)]

Hello! I managed to build everything, I fixed a small problem where libgfortran was not correctly included. I am attaching the diff here. If there are no complaints or errors, I'll go ahead and commit it.

[g5pw (Aljaž Srebrnič)]

I also think this should really be applied to octave and not octave-devel. I checked the portgroup octave, and this should not break anything with octave-* modules.

[kitchen.andy@…]

Replying to g5pw@…:

Hello! I managed to build everything, I fixed a small problem where libgfortran was not correctly included. I am attaching the diff here. If there are no complaints or errors, I'll go ahead and commit it.

Works for me

[vic@…]

Replying to g5pw@…:

I also think this should really be applied to octave and not octave-devel. I checked the portgroup octave, and this should not break anything with octave-* modules.

I agree. Octave-devel was a misnomer anyway. It has been out-of-date for a long time.

[michaelld (Michael Dickens)]

g5pw: Can you post the whole Portfile? My octave-devel is messed up right now and I'd like to just replace it and try the latest. Thanks!

[g5pw (Aljaž Srebrnič)]

Portfile working with gcc47

[g5pw (Aljaž Srebrnič)]

Posted!

[michaelld (Michael Dickens)]

Thanks! Let me see if I can get anything going using it. IIRC, I was having issues with dependencies (grr).

[michaelld (Michael Dickens)]

The newest Portfile works for me under 10.8.0 in a basic sense; I cannot get +fltk working yet, but I think that's a dependency issue -- fltk-devel has worked well in the past and that part of the Portfile wasn't changed. Took quite a while to coerce gcc47 to install, but I got it after a bit. So, we're quite close IMHO.

If we're going to upgrade "octave" to use this new Portfile, then we need folks out there verifying that many of the octave-* ports work with it; not that they should, but that they do: install, "load inside Octave", and execute as expected without significant errors. I do not use the octave-* ports, but I will install, and try to use inside Octave during runtime, a few just to see what happens.

[g5pw (Aljaž Srebrnič)]

Replying to michaelld@…:

The newest Portfile works for me under 10.8.0 in a basic sense; I cannot get +fltk working yet, but I think that's a dependency issue -- fltk-devel has worked well in the past and that part of the Portfile wasn't changed. Took quite a while to coerce gcc47 to install, but I got it after a bit. So, we're quite close IMHO.

I compiled the fltk variant successfully, but I don't know how to test it...

If we're going to upgrade "octave" to use this new Portfile, then we need folks out there verifying that many of the octave-* ports work with it; not that they should, but that they do: install, "load inside Octave", and execute as expected without significant errors. I do not use the octave-* ports, but I will install, and try to use inside Octave during runtime, a few just to see what happens.

I can do that, but this applies to octave-devel too! so we have to do that anyway... I already updated one, I think the main problems will be that we'll have to update a whole lot of the octave-* ports.

[michaelld (Michael Dickens)]

Re: using FLTK; see ​http://www.gnu.org/software/octave/doc/interpreter/Graphics-Toolkits.html

I'm not sure I follow the rest. What I'm asking for is for folks who already use both octave and octave-* ports to: replace octave's Portfile with the new one here, install the new octave, then try installing and using some of the octave-* ports to verify that they both install and work as expected.

[michaelld (Michael Dickens)]

So, I think if you're in octave, and you do

available_graphics_toolkits()

it will return a list of available toolkits that you can select from. If octave+fltk is installed, then 'fltk' should appear in this list; if it does, then you should be able to do:

graphics_toolkit('fltk')

to select it; I think I had to issue this command twice to get it to work. Then do

plot (1:10)

to see what happens. It should be obvious if fltk is being used, or if some other toolkit is still in place.

[g5pw (Aljaž Srebrnič)]

Replying to michaelld@…:

So, I think if you're in octave, and you do

available_graphics_toolkits()

it will return a list of available toolkits that you can select from. If octave+fltk is installed, then 'fltk' should appear in this list; if it does, then you should be able to do:

graphics_toolkit('fltk')

to select it; I think I had to issue this command twice to get it to work. Then do

plot (1:10)

to see what happens. It should be obvious if fltk is being used, or if some other toolkit is still in place.

Well, it works for me!

I'm not sure I follow the rest. What I'm asking for is for folks who already use both octave and octave-* ports to: replace octave's Portfile with the new one here, install the new octave, then try installing and using some of the octave-* ports to verify that they both install and work as expected.

I'm sorry: what I was saying is: if you install a octave-* port, it installs with the octave-devel port, too. So we must update the octave-* even if we keep the old octave port.

[michaelld (Michael Dickens)]

That's great that FLTK works for you. I'm stuck on getting "plotutils" to correctly install as +universal on 10.8; it installs, but just a stub for x86 (32-bit). I know where the issue is in the linking, but I'm not sure where to correct it yet. I'll figure it out later today or tomorrow; got some "real work" to do this morning :)

With regard to octave-* ports: I see that the PortGroup for octave contains "depends_lib path:bin/octave:octave" which means that the octave-* ports are designed to work with either octave or octave-devel (or, any other port that installs ${prefix}/bin/octave). So, we can test the octave-* ports using this new Portfile as "octave-devel", right? Or, am I still not getting it? Why do we need to update the octave-* ports even if we keep the old octave port? Do the octave-* ports not work with Octave 3.2? Only with 3.4 or newer? Only with 3.6?

[g5pw (Aljaž Srebrnič)]

Replying to michaelld@…:

That's great that FLTK works for you. I'm stuck on getting "plotutils" to correctly install as +universal on 10.8; it installs, but just a stub for x86 (32-bit). I know where the issue is in the linking, but I'm not sure where to correct it yet. I'll figure it out later today or tomorrow; got some "real work" to do this morning :)

With regard to octave-* ports: I see that the PortGroup for octave contains "depends_lib path:bin/octave:octave" which means that the octave-* ports are designed to work with either octave or octave-devel (or, any other port that installs ${prefix}/bin/octave). So, we can test the octave-* ports using this new Portfile as "octave-devel", right? Or, am I still not getting it? Why do we need to update the octave-* ports even if we keep the old octave port? Do the octave-* ports not work with Octave 3.2? Only with 3.4 or newer? Only with 3.6?

yes, you got it! We need to update them anyway because if we keep octave 3.2 and bump octave-devel 3.6 and a user installs octave-devel and then tries to install octave-odepack it won't build (actually, now it does because I updated it :).

[michaelld (Michael Dickens)]

Ah; so what you're saying is that the octave-* ports, or at least most of them, are designed to work with Octave 3.2 and may or not work with Octave 3.4 or 3.6? That would make some sense, and I think that's a reason why we've kept Octave at 3.2 -- for compatibility with the octave-* ports. I didn't realize that the octave portgroup already was designed to work with both octave and octave-devel. In that light, assuming I'm understanding it correctly, then I think it would make sense to bump octave-devel to this Portfile just to get folks using it & leave the octave portfile alone just right now. Then once another maintainer (or, you) can be found s/he can deal with bumping the octave port and fixing the octave-* ports to work with the update. How does this grab you?

[g5pw (Aljaž Srebrnič)]

Excellent, that makes a lot of sense. I'll try to update as many octave-* ports as I can, it should be quite easy.

[michaelld (Michael Dickens)]

OK; I'll go ahead and check in this new Portfile as "octave-devel", since it seems to work well enough.

[michaelld (Michael Dickens)]

This ticket is addressed in r97159. I'm closing this ticket as fixed, since I believe the new Portfile addresses the specific issue of this ticket. If someone still has the same issue, then reopen this ticket and we'll figure a way to fix it. If anyone has some other issue with the new octave-devel, then open a new ticket.