Minor configuration items

[Michael D. Godfrey]

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
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Thomas Treichl]

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
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael D. Godfrey]

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.

Michael



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

[John W. Eaton]

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

[Michael D. Godfrey]

>
> 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.
I am sure that I do not understand this either.  If the change above
does not do
any harm, please go ahead.  I will try a new compilation on my Mac 10.5.3.

Michael

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