Re: Minor configuration items

On 18-May-2008, Michael D. Godfrey wrote:

| >
| > Michael D. Godfrey schrieb:
| >> I compiled 3.0.1 release and the current development hg
| >> on my MacBook Pro (10.5.2) laptop and found:
| >>
| >> 1. It was necessary to install the usual "extras."  The main
| >>     problem with this was that the qhull source does not compile
| >>     correctly (using gcc 4.3) if the default -O2 option is used.
| >>     The result is an immediate seq fault in geom.c
| >>     Removing the option -O2 fixes the problem.
| >>
| >> 2. With all "extras" installed, 3.0.1 compiles and installs without
| >> problem.     But the default branch dies when building
| >> liboctave.dylib with:
| >>
| >>     ld: duplicate symbol Array<long long>::Array(Array<long long>
| >> const&) in
| >>     pic/Array-so.o and pic/Array-i.o.
| >>     This happens with gcc 4.3 and with gcc 4.0.
| >>
| >> Since the problem above is fixed in 3.0.1, it should not be hard to
| >> discover
| >> why it fails in the development branch.  But, if any more information
| >> is needed
| >> please tell me.  Needless to say, both 3.0.1 and devel compile fine
| >> on Linux f8.
| >>
| >> Michael Godfrey
| >
| > Hi Michael,
| >
| > the (2.) problem currently is there for Mac in the default branch. The
| > solution to make linking work again is to comment out
| >
| >   INSTANTIATE_ARRAY_AND_ASSIGN (std::streamoff, OCTAVE_API);
| >
| > in Array-so.cc then linking can be done. The discussion about the
| > problem can be found here
| >
| >  
| > https://www.cae.wisc.edu/pipermail/octave-maintainers/2008-April/006836.html 
| >
| >
| > Regards,
| >
| >   Thomas
| This change does allow compilation to complete, but the resulting
| octave (on Intel Mac) has trouble reading input.  After some quick
| experiments,
| it appears that the problem has to do with end-of-line.  Appending input
| lines
| with  blanks and/or # changes the behavior.
|
| Note that Mac OS 10.5.2 on Intel is 32-bit architecture, but supports
| "long long".
| This is part of the reason why the duplicated object problem occurs in
| the first place.

I don't understand why this would happen.  The streamoff type in
Octave (as a wrapper around std::streamoff) isn't used for anything,
at least as far as I can tell.  I have a patch to remove it, and I
don't see why I shouldn't just do that.  I've mentioned this
possibility a few times before and haven't seen any complaints.

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave