[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: About pkg() function and compiling options in mkoctfile
From: |
Kai Torben Ohlhus |
Subject: |
Re: About pkg() function and compiling options in mkoctfile |
Date: |
Sat, 16 May 2020 22:24:46 +0900 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
On 5/16/20 9:29 PM, José Luis García Pallero wrote:
> Hello:
>
> Some days ago I asked about the reason of the -fopenmp is present by
> default in mkoctfile
> (https://lists.gnu.org/archive/html/octave-maintainers/2020-05/msg00057.html)
>
> The reason of my question was that new versions of GCC handle better
> than previous ones with some OpenMP directives. For example, now is
> mandatory to declare explicitly all shared variables in the shared()
> directive when the default(none) option is employed. Prior visions of
> GCC does not require this for variables declared as const, but in the
> standard was always mandatory (see
> http://forum.openmp.org/forum/viewtopic.php?f=3&t=2104). So some code
> must be changed in order to complain with the standard as newer GCC
> versions complain. For example, the GCC provided with Debian stable
> produces error when const variables are declared in shared() (see
> https://sourceforge.net/p/octave/package-releases/417/#681d)
>
> Then, the fact that mkoctfile activates by default the OpenMP support
> makes some cone not compilable in some systems. I can see that the
> -pthread -fopenmp options for mkoctfile are stored in the globals
> ALL_CFLAGS and ALL_CXXFLAGS, which also contain some information about
> include folders
>
> But I think that ask the user to edit manually this variables in order
> to install a package is not a good idea. So I propose to add an option
> to the pkg() function in order to activate or deactivate the OpenMP
> (and pthreads maybe) option. Or maybe more in general an option to
> pass information and options from pkg() to mkoctfile. Or both things.
>
> I think that other discussion could be if mkocfile should activate by
> default the OpenMP dupport
>
> Thanks
>
Thank you for providing more information. You said: "So some code must
be changed". I still do not understand which code is affected? Does
this code contain "#pragma omp" sections that are beyond your control?
In general it sounds like a great idea to change code to follow a
standard, rather than relying on implementation defined behavior. I do
not see a reason to make Octave more complicated, rather than fixing
code to conform to a standard upstream.
Kai