bugGNU Octave - Bugs: bug #59820, build fails on macOS with...

 
 

bug #59820: build fails on macOS with visibility settings

Submitter:  Ben Abbott <bpabbott>
Submitted:  Mon 04 Jan 2021 04:53:54 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  3 - Low Item Group:  Build Failure
Status:  Fixed Assigned to:  None
Originator Name:  Ben Abbott Open/Closed:  * Closed
Release:  * 7.0.90 Operating System:  * Mac OS
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 19 Dec 2021 03:40:57 PM UTC, comment #66: 

I opened bug #61704 for the index vector related test failures with visibility flags on macOS.

Closing this report as fixed.

Markus Mützel <mmuetzel>
Group administrator
Sun 19 Dec 2021 03:14:17 PM UTC, comment #65: 

The latest change seems to have avoided the last two "direct access" warnings for reasons I won't claim to understand. I mainly made that so that packages would be able to include Octave headers on Windows. The fact that it also silences these warnings on macOS is just a "happy coincidence". (But also shows how much of a black box that still is to me...)
https://hg.savannah.gnu.org/hgweb/octave/rev/84344af9b019

Still no change to the index vector related test failures.

This report was originally about a build error with visibility flags on macOS. Octave now builds with these flags on that platform.
Maybe, we should open a new report about the index vector issues and finally close this report as fixed...

Markus Mützel <mmuetzel>
Group administrator
Sat 18 Dec 2021 09:29:23 AM UTC, comment #64: 

I pushed a patch here that moves the forward declaration of many matrix classes to their own forward declaration header:
https://hg.savannah.gnu.org/hgweb/octave/rev/6f07492c9c20

That brings the related warnings on the macOS runner down to two:

ld: warning: direct access in function 'octave::math::sparse_lu<SparseComplexMatrix>::~sparse_lu()' from file 'liboctave/array/.libs/libarray.a(libarray_la-CSparse.o)' to global weak symbol 'vtable for octave::math::sparse_lu<SparseComplexMatrix>' from file 'liboctave/numeric/.libs/libnumeric.a(libnumeric_la-sparse-lu.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'octave::math::sparse_lu<SparseMatrix>::~sparse_lu()' from file 'liboctave/array/.libs/libarray.a(libarray_la-dSparse.o)' to global weak symbol 'vtable for octave::math::sparse_lu<SparseMatrix>' from file 'liboctave/numeric/.libs/libnumeric.a(libnumeric_la-sparse-lu.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.


Still no change to the index vector related test failures though.

Markus Mützel <mmuetzel>
Group administrator
Fri 17 Dec 2021 06:43:14 PM UTC, comment #63: 

I pushed a patch for the cdef-* classes using a forward declaration header here:
https://hg.savannah.gnu.org/hgweb/octave/rev/838e73617671

Markus Mützel <mmuetzel>
Group administrator
Thu 16 Dec 2021 03:21:17 AM UTC, comment #62: 

Thanks.  I pushed one more change.  Maybe we could add a separate check for the <memory_resource> header but for now I'm reusing the HAVE_STD_PMR_POLYMORPHIC_ALLOCATOR macro since that's the only thing we are using the header for.

John W. Eaton <jwe>
Group administrator
Thu 16 Dec 2021 03:03:32 AM UTC, comment #61: 

With the latest change (e9a6d3822244 (stable)) I see with std=c++11:



libtool: compile:  clang++ -DHAVE_CONFIG_H -I. -I.. -DOCTINTERP_DLL -Iliboctave -I../liboctave -I../liboctave/array -Iliboctave/numeric -I../liboctave/numeric -Iliboctave/operators -I../liboctave/operators -I../liboctave/system -I../liboctave/util -I../libinterp/octave-value -Ilibinterp -I../libinterp -I../libinterp/operators -Ilibinterp/parse-tree -I../libinterp/parse-tree -Ilibinterp/corefcn -I../libinterp/corefcn -I../liboctave/wrappers -I/usr/include/GraphicsMagick -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -Dyysymbol_kind_t=octave_tex_symbol_kind_t -fPIC -pthread -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -fvisibility=hidden -std=c++11 -O2 -march=native -mavx -mavx2 -MT libinterp/corefcn/libcorefcn_la-mex.lo -MD -MP -MF libinterp/corefcn/.deps/libcorefcn_la-mex.Tpo -c ../libinterp/corefcn/mex.cc  -fPIC -DPIC -o libinterp/corefcn/.libs/libcorefcn_la-mex.o
../libinterp/corefcn/mex.cc:43:10: fatal error: 'memory_resource' file not found
#include <memory_resource>
         ^~~~~~~~~~~~~~~~~
1 error generated.
make[2]: *** [Makefile:19674: libinterp/corefcn/libcorefcn_la-mex.lo] Error 1


The file is in /usr/include/c++/8/experimental/memory_resource
perhaps my libstdc++ is too old?
(libstdc++-devel-8.5.0-6.el8.x86_64)

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Thu 16 Dec 2021 02:51:18 AM UTC, comment #60: 

It still fails with std=c++11 (before your last change):


configure:13802: checking whether std::pmr::polymorphic_allocator is avalable
configure:13852: clang++ -c -std=c++11 -O2 -march=native -mavx -mavx2  conftest.cpp >&5
conftest.cpp:77:16: fatal error: 'memory_resource' file not found
      #include <memory_resource>
               ^~~~~~~~~~~~~~~~~
1 error generated.
configure:13852: $? = 1



/bin/sh ./libtool  --tag=CXX   --mode=compile clang++ -DHAVE_CONFIG_H -I. -I..  -DOCTINTERP_DLL -Iliboctave -I../liboctave -I../liboctave/array -Iliboctave/numeric -I../liboctave/numeric -Iliboctave/operators -I../liboctave/operators -I../liboctave/system -I../liboctave/util -I../libinterp/octave-value -Ilibinterp -I../libinterp -I../libinterp/operators -Ilibinterp/parse-tree -I../libinterp/parse-tree -Ilibinterp/corefcn -I../libinterp/corefcn -I../liboctave/wrappers  -I/usr/include/GraphicsMagick    -fPIC -pthread -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -fvisibility=hidden -std=c++11 -O2 -march=native -mavx -mavx2 -MT libinterp/dldfcn/__delaunayn___la-__delaunayn__.lo -MD -MP -MF libinterp/dldfcn/.deps/__delaunayn___la-__delaunayn__.Tpo -c -o libinterp/dldfcn/__delaunayn___la-__delaunayn__.lo `test -f 'libinterp/dldfcn/__delaunayn__.cc' || echo '../'`libinterp/dldfcn/__delaunayn__.cc
libtool: compile:  clang++ -DHAVE_CONFIG_H -I. -I.. -DOCTINTERP_DLL -Iliboctave -I../liboctave -I../liboctave/array -Iliboctave/numeric -I../liboctave/numeric -Iliboctave/operators -I../liboctave/operators -I../liboctave/system -I../liboctave/util -I../libinterp/octave-value -Ilibinterp -I../libinterp -I../libinterp/operators -Ilibinterp/parse-tree -I../libinterp/parse-tree -Ilibinterp/corefcn -I../libinterp/corefcn -I../liboctave/wrappers -I/usr/include/GraphicsMagick -fPIC -pthread -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -fvisibility=hidden -std=c++11 -O2 -march=native -mavx -mavx2 -MT libinterp/dldfcn/__delaunayn___la-__delaunayn__.lo -MD -MP -MF libinterp/dldfcn/.deps/__delaunayn___la-__delaunayn__.Tpo -c ../libinterp/dldfcn/__delaunayn__.cc  -fPIC -DPIC -o libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o
In file included from ../libinterp/dldfcn/__delaunayn__.cc:53:
../liboctave/array/Array.h:139:36: error: use 'template' keyword to treat 'rebind_traits' as a dependent template name
    typedef typename Alloc_traits::rebind_traits<T> T_Alloc_traits;
                                   ^
                                   template
1 error generated.


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 16 Dec 2021 02:40:10 AM UTC, comment #59: 

I pushed this change for the "template" required before "rebind_traits" error:

http://hg.savannah.gnu.org/hgweb/octave/rev/e9a6d3822244

I'm not expecting -std=c++17 to be required.  I expected it to continue to compile using a C++11 conformant compiler.  There is a new test to check for std::pmr::polymorphic_allocator.  If that doesn't exist, the old code should be used.  If it does exist, then it will be used.  The check is for the feature.  It doesn't use the value of the __cplusplus macro to decide.  Is the check wrong?  Does it succeed with Clang and then not actually work?  When I build with CXX="g++ -std=c++11" configure doesn't find std::pmr::polymorphic_allocator so doesn't define HAVE_STD_PMR_POLYMORPHIC_ALLOCATOR in config.h and the build succeeds.

John W. Eaton <jwe>
Group administrator
Thu 16 Dec 2021 02:10:33 AM UTC, comment #58: 

But even with srd=c++17 I see:


/bin/sh ./libtool  --tag=CXX   --mode=compile clang++ -DHAVE_CONFIG_H -I. -I..  -DOCTINTERP_DLL -Iliboctave -I../liboctave -I../liboctave/array -Iliboctave/numeric -I../liboctave/numeric -Iliboctave/operators -I../liboctave/operators -I../liboctave/system -I../liboctave/util -I../libinterp/octave-value -Ilibinterp -I../libinterp -I../libinterp/operators -Ilibinterp/parse-tree -I../libinterp/parse-tree -Ilibinterp/corefcn -I../libinterp/corefcn -I../liboctave/wrappers  -I/usr/include/GraphicsMagick    -fPIC -pthread -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -fvisibility=hidden -std=c++17 -O2 -march=native -mavx -mavx2 -MT libinterp/dldfcn/__delaunayn___la-__delaunayn__.lo -MD -MP -MF libinterp/dldfcn/.deps/__delaunayn___la-__delaunayn__.Tpo -c -o libinterp/dldfcn/__delaunayn___la-__delaunayn__.lo `test -f 'libinterp/dldfcn/__delaunayn__.cc' || echo '../'`libinterp/dldfcn/__delaunayn__.cc
libtool: compile:  clang++ -DHAVE_CONFIG_H -I. -I.. -DOCTINTERP_DLL -Iliboctave -I../liboctave -I../liboctave/array -Iliboctave/numeric -I../liboctave/numeric -Iliboctave/operators -I../liboctave/operators -I../liboctave/system -I../liboctave/util -I../libinterp/octave-value -Ilibinterp -I../libinterp -I../libinterp/operators -Ilibinterp/parse-tree -I../libinterp/parse-tree -Ilibinterp/corefcn -I../libinterp/corefcn -I../liboctave/wrappers -I/usr/include/GraphicsMagick -fPIC -pthread -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -fvisibility=hidden -std=c++17 -O2 -march=native -mavx -mavx2 -MT libinterp/dldfcn/__delaunayn___la-__delaunayn__.lo -MD -MP -MF libinterp/dldfcn/.deps/__delaunayn___la-__delaunayn__.Tpo -c ../libinterp/dldfcn/__delaunayn__.cc  -fPIC -DPIC -o libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o
In file included from ../libinterp/dldfcn/__delaunayn__.cc:53:
../liboctave/array/Array.h:139:36: error: use 'template' keyword to treat 'rebind_traits' as a dependent template name
    typedef typename Alloc_traits::rebind_traits<T> T_Alloc_traits;
                                   ^
                                   template
1 error generated.


Dmitri A. Sergatskov <dasergatskov>
Thu 16 Dec 2021 02:07:31 AM UTC, comment #57: 

If I read https://clang.llvm.org/cxx_status.html correctly
clang by default now is std+14 only bit support up to c++20
via option.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 16 Dec 2021 01:54:42 AM UTC, comment #56: 

buildbots are failing...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 16 Dec 2021 01:39:08 AM UTC, comment #55: 

I checked in a series of changesets that might help somewhat with the visibility issues.  I'm done for now.  See also the comments I made for bug #61472.

John W. Eaton <jwe>
Group administrator
Wed 15 Dec 2021 05:14:50 PM UTC, comment #54: 

@Markus: Maybe it was this comment?  https://savannah.gnu.org/bugs/?61472#comment30

I will work on my pending changes today and see if there are other forward declaration changes that I can easily make.  I'll let you know once I'm done.  Sorry for the delay.

John W. Eaton <jwe>
Group administrator
Wed 15 Dec 2021 09:24:18 AM UTC, comment #53: 

@jwe: I was assuming that you had changes for this almost ready. (I don't recall why now. Maybe something I read in a different bug report?) So, I stopped working on it.

It would still be good to have the visibility changes sorted out before the release of Octave 7.

If you don't come around to it, I could start looking at this again. Maybe during the weekend. But I'd prefer to avoid duplicating your work...

Markus Mützel <mmuetzel>
Group administrator
Mon 06 Dec 2021 04:20:07 PM UTC, comment #52: 

Please, go ahead and do those changes.
If it is ok with you, I could try and follow your lead and similarly fix the remaining warnings. (If it is a similarly simple change.)

The "real" remaining issue here is the failing tests related to index vectors when compiling with visibility flags (see comment #42).
I'm no longer sure the warnings and those errors are directly related. The last remaining ones don't seem to be very much related with index vectors. But the failing tests persist...

It might still be that we forward declare idx_vector, range or a related class somewhere without the correct visibility flags. Or something entirely different...

Markus Mützel <mmuetzel>
Group administrator
Mon 06 Dec 2021 04:04:50 PM UTC, comment #51: 

Could we put the forward declarations for the cdef_* classes in a separate header file?  I would prefer that to having these #defines repeated in multiple files.  Maybe also make the forward declaration changes and the addition of OCTINTERP_API tags in separate changesets?  I can do that if you would like me to.  Otherwise, I think the change is fine.

John W. Eaton <jwe>
Group administrator
Mon 06 Dec 2021 01:45:02 PM UTC, comment #50: 

Using the patch in comment #49 avoids the warnings about cdef_* classes and brings the number of warnings down to the eight remaining that seem all to be related to the SparseMatrix and/or SparseComplexMatrix classes.

That patch looks pretty save to me. And it probably will help the compiler also on other platform. Would it be ok to still push it on stable?

Markus Mützel <mmuetzel>
Group administrator
Sun 05 Dec 2021 06:20:01 PM UTC, comment #49: 

An alternative to adding dedicated forward declaration headers would be to guard the forward declarations themselves.
See the attached patch for a possible change for the cdef_* classes.

Would that coding pattern be acceptable?

(file #52435)

Markus Mützel <mmuetzel>
Group administrator
Sun 05 Dec 2021 05:46:14 PM UTC, comment #48: 

My current understanding is that the issue is with our forward declarations. They have to be done with the correct visibility flags or the visibility flags at the "proper" declaration are ignored.
The fact that any object can only be (forward) declared with visibility flags once per compilation unit (at least for some platforms) complicates any change.
Using the forward-declaration headers with inclusion guards is one possible solution.

I guess that - once this is sorted out - we can probably remove the visibility flags from (most of) the member functions. While we are still forward declaring with the wrong (i.e., without) visibility flags in some places, we still need those flags at the member functions.

Markus Mützel <mmuetzel>
Group administrator
Sun 05 Dec 2021 03:38:27 PM UTC, comment #47: 

Just to be clear, I don't object to the forward declaration changes, but any other sweeping changes to visibility should probably be done on the development branch.


John W. Eaton <jwe>
Group administrator
Sun 05 Dec 2021 03:26:18 PM UTC, comment #46: 

While looking at bug #61472 and what libstdc++ does for template classes like <vector>, I noticed that they appear to always force default visibility for the templates and it is done as a namespace visibility attribute, not as visibility attributes for individual member functions in the class.  The <vector> header also includes the declarations and definitions for everything in the template so that implicit instantiation is possible.  There are no explicit instantiaitions.  Maybe we should be doing the same?  I tried to make that happen, but given the way things are currently done, it is not an easy change to make.  Probably all of this should be deferred until after the version 7 release and all these changes can be done on the default branch, not stable.

John W. Eaton <jwe>
Group administrator
Sun 05 Dec 2021 03:16:09 PM UTC, comment #45: 

I pushed two patches that should make sure that more template classes are (forward) declared with the correct visibility settings:
https://hg.savannah.gnu.org/hgweb/octave/rev/c6cd2f582254
https://hg.savannah.gnu.org/hgweb/octave/rev/1f0a2689cab2

Previously, jwe pushed this changeset:
https://hg.savannah.gnu.org/hgweb/octave/rev/e38202d3628d

With those, the compiler warnings like the ones shown in comment #41 have greatly reduced on the GitHub runners afaics. Remaining ones are:

2021-12-05T14:38:19.6454710Z ld: warning: direct access in function 'octave::math::sparse_lu<SparseComplexMatrix>::~sparse_lu()' from file 'liboctave/array/.libs/libarray.a(libarray_la-CSparse.o)' to global weak symbol 'vtable for octave::math::sparse_lu<SparseComplexMatrix>' from file 'liboctave/numeric/.libs/libnumeric.a(libnumeric_la-sparse-lu.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
2021-12-05T14:38:19.6467310Z ld: warning: direct access in function 'SparseMatrix::inverse(MatrixType&, long long&, double&, bool, bool) const' from file 'liboctave/array/.libs/libarray.a(libarray_la-dSparse.o)' to global weak symbol 'vtable for octave::math::sparse_chol<SparseMatrix>' from file 'liboctave/numeric/.libs/libnumeric.a(libnumeric_la-sparse-chol.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
2021-12-05T14:38:19.6526100Z ld: warning: direct access in function 'SparseMatrix::inverse(MatrixType&, long long&, double&, bool, bool) const' from file 'liboctave/array/.libs/libarray.a(libarray_la-dSparse.o)' to global weak symbol 'vtable for octave::math::sparse_chol<SparseMatrix>' from file 'liboctave/numeric/.libs/libnumeric.a(libnumeric_la-sparse-chol.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
2021-12-05T14:38:19.6531600Z ld: warning: direct access in function 'octave::math::sparse_chol<SparseMatrix>::~sparse_chol()' from file 'liboctave/array/.libs/libarray.a(libarray_la-dSparse.o)' to global weak symbol 'vtable for octave::math::sparse_chol<SparseMatrix>' from file 'liboctave/numeric/.libs/libnumeric.a(libnumeric_la-sparse-chol.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
2021-12-05T14:38:19.6539520Z ld: warning: direct access in function 'octave::math::sparse_chol<SparseMatrix>::~sparse_chol()' from file 'liboctave/array/.libs/libarray.a(libarray_la-dSparse.o)' to global weak symbol 'vtable for octave::math::sparse_chol<SparseMatrix>' from file 'liboctave/numeric/.libs/libnumeric.a(libnumeric_la-sparse-chol.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
2021-12-05T14:38:19.6645690Z ld: warning: direct access in function 'octave::math::sparse_lu<SparseMatrix>::~sparse_lu()' from file 'liboctave/array/.libs/libarray.a(libarray_la-dSparse.o)' to global weak symbol 'vtable for octave::math::sparse_lu<SparseMatrix>' from file 'liboctave/numeric/.libs/libnumeric.a(libnumeric_la-sparse-lu.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
2021-12-05T14:38:19.6724270Z ld: warning: direct access in function 'make_cholb(SparseMatrix&, SparseMatrix&, ColumnVector&)' from file 'liboctave/numeric/.libs/libnumeric.a(libnumeric_la-eigs-base.o)' to global weak symbol 'vtable for octave::math::sparse_chol<SparseMatrix>' from file 'liboctave/numeric/.libs/libnumeric.a(libnumeric_la-sparse-chol.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
2021-12-05T14:38:19.6747560Z ld: warning: direct access in function 'make_cholb(SparseMatrix&, SparseMatrix&, ColumnVector&)' from file 'liboctave/numeric/.libs/libnumeric.a(libnumeric_la-eigs-base.o)' to global weak symbol 'vtable for octave::math::sparse_chol<SparseMatrix>' from file 'liboctave/numeric/.libs/libnumeric.a(libnumeric_la-sparse-chol.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
2021-12-05T14:38:31.6039290Z ld: warning: direct access in function 'octave::cdef_object_array::subsasgn(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::list<octave_value_list, std::__1::allocator<octave_value_list> > const&, octave_value const&)' from file 'libinterp/octave-value/.libs/liboctave-value.a(liboctave_value_la-cdef-object.o)' to global weak symbol 'vtable for Array<octave::cdef_object>' from file 'libinterp/template-inst/.libs/liboctinterp_la-Array-tc.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
2021-12-05T14:38:31.6044500Z ld: warning: direct access in function 'octave::cdef_object_array::array_value() const' from file 'libinterp/octave-value/.libs/liboctave-value.a(liboctave_value_la-cdef-object.o)' to global weak symbol 'vtable for Array<octave::cdef_object>' from file 'libinterp/template-inst/.libs/liboctinterp_la-Array-tc.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
2021-12-05T14:38:31.6049060Z ld: warning: direct access in function 'octave::cdef_object_array::cdef_object_array()' from file 'libinterp/octave-value/.libs/liboctave-value.a(liboctave_value_la-cdef-object.o)' to global weak symbol 'vtable for Array<octave::cdef_object>' from file 'libinterp/template-inst/.libs/liboctinterp_la-Array-tc.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
2021-12-05T14:38:31.6053750Z ld: warning: direct access in function 'octave::cdef_object_array::cdef_object_array(Array<octave::cdef_object> const&)' from file 'libinterp/octave-value/.libs/liboctave-value.a(liboctave_value_la-cdef-object.o)' to global weak symbol 'vtable for Array<octave::cdef_object>' from file 'libinterp/template-inst/.libs/liboctinterp_la-Array-tc.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
2021-12-05T14:38:31.6059160Z ld: warning: direct access in function 'octave::cdef_object_array::cdef_object_array(octave::cdef_object_array const&)' from file 'libinterp/octave-value/.libs/liboctave-value.a(liboctave_value_la-cdef-object.o)' to global weak symbol 'vtable for Array<octave::cdef_object>' from file 'libinterp/template-inst/.libs/liboctinterp_la-Array-tc.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.


However, the tests shown in comment #42 are still failing when compiling with visibility flags. They are passing when compiling without visibility flags.
They don't look related to the above warnings. But something is still off with how we use visibility (at least on macOS).

Markus Mützel <mmuetzel>
Group administrator
Wed 24 Nov 2021 06:13:18 PM UTC, comment #44: 

As a temporary measure in case no one finds a fix in time, I disabled the lib visibility flags on macOS by default on the stable branch:
http://hg.savannah.gnu.org/hgweb/octave/rev/29efaa1d32d7

They are still enabled by default (like on all other platforms) on the default branch.

Markus Mützel <mmuetzel>
Group administrator
Wed 29 Sep 2021 07:28:36 AM UTC, comment #43: 

Pinging this report for the issue that was briefly touched in yesterday's developer meeting.

Markus Mützel <mmuetzel>
Group administrator
Wed 12 May 2021 01:39:43 PM UTC, comment #42: 

Additionally to the warnings, there are some tests that are failing on macOS with visibility flags enabled:

>>>>> processing /Users/runner/work/octave/octave/.build/liboctave/array/idx-vector.cc-tst
***** error id=Octave:index-out-of-bounds 1(find ([1,1] != 0))
!!!!! error failed.
Expected id=Octave:index-out-of-bounds, but got <>


>>>>> processing /Users/runner/work/octave/octave/.build/libinterp/corefcn/sub2ind.cc-tst
***** error <index \(0,_,_\)> sub2ind ([10 10 10], 0, 1, 1)
!!!!! error failed.
Expected <index \(0,_,_\)>, but got <index 0: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <index \(_,0,_\)> sub2ind ([10 10 10], 1, 0, 1)
!!!!! error failed.
Expected <index \(_,0,_\)>, but got <index 0: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <index \(_,_,0\)> sub2ind ([10 10 10], 1, 1, 0)
!!!!! error failed.
Expected <index \(_,_,0\)>, but got <index 0: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <index \(1.5,_\)> sub2ind ([10 10], 1.5, 1)
!!!!! error failed.
Expected <index \(1.5,_\)>, but got <index 1.5: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <index \(_,1.5\)> sub2ind ([10 10], 1, 1.5)
!!!!! error failed.
Expected <index \(_,1.5\)>, but got <index 1.5: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <invalid index> ind2sub ([2, 2, 2], -1:8)
!!!!! error failed.
Expected <invalid index>, but got <index -1: subscripts must be either integers 1 to (2^63)-1 or logicals>


>>>>> processing /Users/runner/work/octave/octave/test/index.tst
***** error <index \(0\): subscripts must be>     1(0)
!!!!! error failed.
Expected <index \(0\): subscripts must be>, but got <index 0: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <index \(-1\): subscripts must be>    1(-1)
!!!!! error failed.
Expected <index \(-1\): subscripts must be>, but got <index -1: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <index \(_,0.5\): subscripts>                 {}(1,0.5)
!!!!! error failed.
Expected <index \(_,0.5\): subscripts>, but got <index 0.5: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <index \([Nn][aA][Nn],_\): subscripts>                 1(NaN,1)
!!!!! error failed.
Expected <index \([Nn][aA][Nn],_\): subscripts>, but got <index nan: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <index \(_,_,<cell....\[x8\]...\): subscripts> [](1,1,{},1,1,1,1,1,1,1,1)
!!!!! error failed.
Expected <index \(_,_,<cell....\[x8\]...\): subscripts>, but got <index <cell>: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <index \(...\[x9\]...-1,_\): subscript>      1(1,1,1,1,1,1,1,1,1,-1,1)
!!!!! error failed.
Expected <index \(...\[x9\]...-1,_\): subscript>, but got <index -1: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <index \(-1\): subscripts>                   1(1)(-1)(1)
!!!!! error failed.
Expected <index \(-1\): subscripts>, but got <index -1: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(3\): out of bound 2>      abc([false, true, true])
!!!!! error failed.
Expected <abc\(3\): out of bound 2>, but got <index (3): out of bound 2 (dimensions are 1x2)>

***** error <abc\(-1\): subscripts>         abc(-1)(1)(1)
 ## xerror <index \(-1\): subscripts> abc(1)(-1)(1)   ## why no 'xerror' test?
!!!!! error failed.
Expected <abc\(-1\): subscripts>, but got <index -1: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(5\): out of bound 4>         abc(5)
!!!!! error failed.
Expected <abc\(5\): out of bound 4>, but got <index (5): out of bound 4 (dimensions are 2x2)>

***** error <abc\(_,3\): out of bound 2 \(dimensions are 2x2\)> abc(2,3)
!!!!! error failed.
Expected <abc\(_,3\): out of bound 2 \(dimensions are 2x2\)>, but got <index (_,3): out of bound 2 (dimensions are 2x2)>

***** error <abc\(_,_,0.5\): subscripts>       exp (abc(2,3,0.5))
!!!!! error failed.
Expected <abc\(_,_,0.5\): subscripts>, but got <index 0.5: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(_,5\): out of bound 4>                            abc(2,5)
!!!!! error failed.
Expected <abc\(_,5\): out of bound 4>, but got <index (_,5): out of bound 4 (dimensions are 2x2x2)>

***** error <abc\(_,3,_\): out of bound 2 \(dimensions are 2x2x2\)> abc(2,3,2)
!!!!! error failed.
Expected <abc\(_,3,_\): out of bound 2 \(dimensions are 2x2x2\)>, but got <index (_,3,_): out of bound 2 (dimensions are 2x2x2)>

***** error <index \(-2,_\): subscripts>               eye (4)(-2,3)
!!!!! error failed.
Expected <index \(-2,_\): subscripts>, but got <index -2: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(_,0.3,_\): subscripts>  abc(2,0.3,5)
!!!!! error failed.
Expected <abc\(_,0.3,_\): subscripts>, but got <index 0.3: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(_,0.3,_\): subscripts>  abc{2,0.3,5}
!!!!! error failed.
Expected <abc\(_,0.3,_\): subscripts>, but got <index 0.3: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(-2,_,_,_\): subscripts> abc{-2,1,1,1}
!!!!! error failed.
Expected <abc\(-2,_,_,_\): subscripts>, but got <index -2: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(0,_,_,_\): subscripts>  abc(0,1,1,1) = 1
!!!!! error failed.
Expected <abc\(0,_,_,_\): subscripts>, but got <index 0: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\([Nn][aA][Nn]\): subscripts>         abc(NA)
!!!!! error failed.
Expected <abc\([Nn][aA][Nn]\): subscripts>, but got <index nan: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(_,_,_,[Ii][nN][Ff],_\): subscripts> abc(1,1,1,Inf,1)
!!!!! error failed.
Expected <abc\(_,_,_,[Ii][nN][Ff],_\): subscripts>, but got <index inf: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(-1\): subscripts>                abc(-1)
!!!!! error failed.
Expected <abc\(-1\): subscripts>, but got <index -1: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(-1\): subscripts>                abc(-1) = 1
!!!!! error failed.
Expected <abc\(-1\): subscripts>, but got <index -1: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(-1,_\): subscripts>              abc(-1,1)
!!!!! error failed.
Expected <abc\(-1,_\): subscripts>, but got <index -1: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(-1,_\): subscripts>              abc(-1,1) = 1
!!!!! error failed.
Expected <abc\(-1,_\): subscripts>, but got <index -1: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(4,_\): out of bound 3 \(dimensions are 3x3\)> abc(4,1)
!!!!! error failed.
Expected <abc\(4,_\): out of bound 3 \(dimensions are 3x3\)>, but got <index (4,_): out of bound 3 (dimensions are 3x3)>

***** error <abc\(-1\): subscripts>             abc(-1)
!!!!! error failed.
Expected <abc\(-1\): subscripts>, but got <index -1: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(-1,_\): subscripts>           abc(-1,1)
!!!!! error failed.
Expected <abc\(-1,_\): subscripts>, but got <index -1: subscripts must be either integers 1 to (2^63)-1 or logicals>

***** error <abc\(4,_\): out of bound 1 \(dimensions are 1x10\)> abc(4,1)
!!!!! error failed.
Expected <abc\(4,_\): out of bound 1 \(dimensions are 1x10\)>, but got <index (4,_): out of bound 1 (dimensions are 1x10)>


>>>>> processing /Users/runner/work/octave/octave/test/logical-index.tst
***** error id=Octave:index-out-of-bounds a(logical ([1,1]))
!!!!! error failed.
Expected id=Octave:index-out-of-bounds, but got <>


>>>>> processing /Users/runner/work/octave/octave/test/struct.tst
***** error id=Octave:index-out-of-bounds
 a(1).x.x = 1;
 a(2).x;
!!!!! error failed.
Expected id=Octave:index-out-of-bounds, but got <>

***** error id=Octave:index-out-of-bounds
 s = resize (struct (),3,2);
 s(3).foo = 42;
 s(7);
!!!!! error failed.
Expected id=Octave:index-out-of-bounds, but got <>



Markus Mützel <mmuetzel>
Group administrator
Wed 12 May 2021 06:46:23 AM UTC, comment #41: 

I pushed a follow-up patch that lets the GitHub macOS runner build with visibility flags here:
https://hg.savannah.gnu.org/hgweb/octave/rev/0230f7cf4044

This seems to be working now.

So this wasn't a compiler/vendor difference after all. We've been compiling with "-fvisibility=hidden" but didn't add any visibility attributes to declarations on macOS.

The linker emits quite a few warnings like the following though:

ld: warning: direct access in function 'boolMatrix::diag(long long) const' from file 'liboctave/array/.libs/libarray.a(libarray_la-boolMatrix.o)' to global weak symbol 'vtable for Array<bool>' from file 'liboctave/array/.libs/libarray.a(libarray_la-Array-b.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
[...]
ld: warning: direct access in function 'SparseBoolMatrix::concat(SparseBoolMatrix const&, Array<long long> const&)' from file 'liboctave/array/.libs/libarray.a(libarray_la-boolSparse.o)' to global weak symbol 'vtable for Sparse<bool>' from file 'liboctave/array/.libs/libarray.a(libarray_la-Sparse-b.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.


There might be something off with how we declare the template classes Array<T> and Sparse<T>.
IIRC, it was tricky to get the visibility flags right so that both clang and gcc would accept them.
Maybe something is still not quite right.

Markus Mützel <mmuetzel>
Group administrator
Tue 11 May 2021 06:47:05 PM UTC, comment #40: 

I pushed a patch that sets the necessary compiler flags when necessary (also on macOS) here:
https://hg.savannah.gnu.org/hgweb/octave/rev/bdb0cfffa2d0

Marking as ready for test.

Markus Mützel <mmuetzel>
Group administrator
Tue 11 May 2021 05:23:23 PM UTC, comment #39: 

The reason for the the compilation no longer failing when linking the libraries is probably not due to the changes for bug #60567.
It's more likely related to this change:
https://hg.savannah.gnu.org/hgweb/octave/rev/b4cb9d04f3cf

That added "-undefined dynamic_lookup" to the linker flags on macOS. So the libraries no longer complain about the missing symbols.

I noticed that -DOCTAVE_API and similar flags are missing from the compilation commands on macOS.
I'll have a look at why that is.

Markus Mützel <mmuetzel>
Group administrator
Tue 11 May 2021 01:18:29 PM UTC, comment #38: 

After the changes for bug #60567, linking liboctave and liboctinterp seems to succeed when visibility flags are enabled.

But the build process still fails later on with:

/bin/sh ./libtool  --tag=CXX   --mode=link ccache clang++ -fPIC -D_THREAD_SAFE -pthread -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -fvisibility=hidden -O2 -g -std=c++11     -L/usr/local/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/gettext/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib  -o src/octave-cli src/octave_cli-main-cli.o src/octave_cli-octave-build-info.o libinterp/liboctinterp.la liboctave/liboctave.la libgnu/libgnu.la  -lm
libtool: link: ccache clang++ -fPIC -D_THREAD_SAFE -pthread -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -fvisibility=hidden -O2 -g -std=c++11 -o src/.libs/octave-cli src/octave_cli-main-cli.o src/octave_cli-octave-build-info.o -Wl,-bind_at_load  -L/usr/local/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/gettext/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib libinterp/.libs/liboctinterp.dylib -L/usr/local/Cellar/graphicsmagick/1.3.36/lib -L/usr/local/Cellar/fftw/3.3.9_1/lib -L/usr/local/Cellar/arpack/3.8.0_1/libexec/lib -L/usr/local/Cellar/pcre/8.44/lib -L/usr/local/opt/openblas/lib -L/usr/local/Cellar/gcc/11.1.0/lib/gcc/11/gcc/x86_64-apple-darwin19/11.1.0 -L/usr/local/Cellar/gcc/11.1.0/lib/gcc/11/gcc/x86_64-apple-darwin19/11.1.0/../../.. -L/usr/local/opt/freetype/lib /Users/runner/work/octave/octave/.build/liboctave/.libs/liboctave.dylib -lhdf5 /usr/local/Cellar/graphicsmagick/1.3.36/lib/libGraphicsMagick++.dylib /usr/local/Cellar/graphicsmagick/1.3.36/lib/libGraphicsMagick.dylib -llcms2 -lbz2 -lltdl -lpthread -lz -lfontconfig -lfreetype -lgl2ps liboctave/.libs/liboctave.dylib -lcurl -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -lsuitesparseconfig -lspqr /usr/local/Cellar/arpack/3.8.0_1/libexec/lib/libarpack.dylib -lqrupdate -lfftw3_threads -lfftw3 -lfftw3f_threads -lfftw3f -lopenblas -lreadline -lncurses -lpcre -ldl -lgfortran -lquadmath libgnu/.libs/libgnu.a -liconv -lm -framework Carbon -framework OpenGL -pthread
Undefined symbols for architecture x86_64:
  "liboctave_hg_id()", referenced from:
      _main in octave_cli-main-cli.o
  "liboctinterp_hg_id()", referenced from:
      _main in octave_cli-main-cli.o
  "octave::application::application(int, char**)", referenced from:
      _main in octave_cli-main-cli.o
  "octave::application::~application()", referenced from:
      _main in octave_cli-main-cli.o
  "octave::cli_application::execute()", referenced from:
      _main in octave_cli-main-cli.o
  "octave::sys::env::set_program_name(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      _main in octave_cli-main-cli.o
  "vtable for octave::cli_application", referenced from:
      _main in octave_cli-main-cli.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
  "_octave_block_async_signals", referenced from:
      _main in octave_cli-main-cli.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


Those are functions declared in libinterp/octave.h, liboctave/system/oct-env.h and liboctave/wrappers/signal-wrappers.h afaict.

Markus Mützel <mmuetzel>
Group administrator
Mon 25 Jan 2021 12:48:43 PM UTC, comment #37: 

I also just built release 843b1f794544 with no errors using
the new flag for disbling visibility flags.

So I confirm this also works on macos 11.1

I agree the ticket should be left open until we can find a way
to enable this feature on macos


Carlo de Falco <cdf>
Group Member
Sun 24 Jan 2021 12:46:04 AM UTC, comment #36: 

I'll pulled/updated and am able to build with the configure flag --disable-lib-visibility-flags.

If there are no objections, let's leave this open.

Ben Abbott <bpabbott>
Group Member
Sat 23 Jan 2021 11:13:54 AM UTC, comment #35: 

Thank you for testing

I merge jwe's and my proposed name for the configure switch into "--disable-lib-visibility-flags", added a missing part to make this work for the Windows targets (untested), and pushed the change here:
https://hg.savannah.gnu.org/hgweb/octave/rev/6dea3b384846

Should we leave this open until building with visibility attributes on macOS is actually fixed?

Markus Mützel <mmuetzel>
Group administrator
Sat 23 Jan 2021 05:13:10 AM UTC, comment #34: 

@Markus, I'm able to build with your patch.

Ben Abbott <bpabbott>
Group Member
Fri 22 Jan 2021 04:28:36 PM UTC, comment #33: 

There has been a considerable amount of changes to these template class and function after 1af06a145d40 (among others a fix for compiling with clang in f207504ae98d).
If these linker errors still occur with the changes in comment #17 on a current tip, we should investigate again.

Markus Mützel <mmuetzel>
Group administrator
Fri 22 Jan 2021 04:20:12 PM UTC, comment #32: 

the final error message in my build of release 1af06a145d40
is the same as shown by Ben in comment #20 :


Undefined symbols for architecture x86_64:
  "octave::math::sparse_qr<SparseMatrix>::sparse_qr(SparseMatrix const&, int)", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseMatrix>::~sparse_qr()", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseComplexMatrix>::sparse_qr(SparseComplexMatrix const&, int)", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseComplexMatrix>::~sparse_qr()", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseMatrix>::C(Matrix const&) const", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseMatrix>::Q() const", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseMatrix>::R(bool) const", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseComplexMatrix>::C(ComplexMatrix const&) const", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseComplexMatrix>::Q() const", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseComplexMatrix>::R(bool) const", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libinterp/liboctinterp.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2



Carlo de Falco <cdf>
Group Member
Fri 22 Jan 2021 04:16:46 PM UTC, comment #31: 


comment #30:

> I will try the patch from comment #17 but I wonder how
> the visibility flags can cause the build fail on 1af06a145d40
> as this version should be before those were introduced ...
>
> could you please elaborate more on what you think is happening there?
>
>


OH, now I see, in comment #28 I referred to the wrong logfile!
so the errors you saw are not related to building this version, that's probably because the file was too long and upload did not work, sorry!

Carlo de Falco <cdf>
Group Member
Fri 22 Jan 2021 04:12:39 PM UTC, comment #30: 

I will try the patch from comment #17 but I wonder how
the visibility flags can cause the build fail on 1af06a145d40
as this version should be before those were introduced ...

could you please elaborate more on what you think is happening there?


Carlo de Falco <cdf>
Group Member
Fri 22 Jan 2021 03:24:53 PM UTC, comment #29: 

I'm not sure it is worth the effort to bisect. It is pretty clear from the error messages that this has to do with the visibility settings.
We won't revert that completely.

There are two ways forward:
Either make visibility work on Mac (for which bisecting will most likely not help).
Or compile without visibility settings on Mac (for which bisecting isn't necessary).

For the second approach, I submitted a patch in comment #17.

Could you please apply it on top of the current default branch, run the bootstrap script, and configure with "--disable-lib-visibility"? Does that lead to a complete build?

Markus Mützel <mmuetzel>
Group administrator
Fri 22 Jan 2021 03:11:38 PM UTC, comment #28: 

@Markus, Yes I started the build from scratch and ran bootstrap before configure

my configure options were the same as in file #50681

I'm trying now to bisect to see what is the first bad release,
right now I have

bad -> 1af06a145d40
good -> 5aa787452544

c.

Carlo de Falco <cdf>
Group Member
Fri 22 Jan 2021 12:20:15 PM UTC, comment #27: 

@Carlo: Same questions like for Ben: Did you build from a clean build tree? Did you run the bootstrap script before configuring?

Markus Mützel <mmuetzel>
Group administrator
Fri 22 Jan 2021 12:03:59 PM UTC, comment #26: 

re: comment #20 and comment #21

also for me release 1af06a145d40 fails.
the output from make is attached as file #50682

I don't see anything related to visibility attributes in that
changeset ...

Carlo de Falco <cdf>
Group Member
Thu 21 Jan 2021 04:06:28 PM UTC, comment #25: 

@Ben: Could you please elaborate? I don't think that the spaces before the opening brackets that we have should make a difference, do they?

Markus Mützel <mmuetzel>
Group administrator
Thu 21 Jan 2021 04:00:17 PM UTC, comment #24: 

@jwe: That is basically what I tried to do with the patch in comment #17. We could rename the configure flag if you prefer the other name.

Markus Mützel <mmuetzel>
Group administrator
Thu 21 Jan 2021 03:49:18 PM UTC, comment #23: 

@Markus,

A quick google and look at source forge, it appears the macOS has different syntax

https://stackoverflow.com/questions/19496643/using-clang-fvisibility-hidden-and-typeinfo-and-type-erasure


#define API __attribute__((visibility("default")))


Ben Abbott <bpabbott>
Group Member
Thu 21 Jan 2021 03:46:40 PM UTC, comment #22: 

For now, I think it might be good to have a --disable-symbol-visibility-flags option for the configure script.  It should be fairly simple to do, right?  It should just need to cause the visibility macros to expand to nothing.

John W. Eaton <jwe>
Group administrator
Thu 21 Jan 2021 03:44:12 PM UTC, comment #21: 

@Ben: Was the build tree clean before you started building? Did you run the bootstrap strip before configuring?

Markus Mützel <mmuetzel>
Group administrator
Thu 21 Jan 2021 03:40:11 PM UTC, comment #20: 

hg update -r 1af06a145d40

[...]
libtool: link: g++ -dynamiclib  -o libinterp/.libs/liboctinterp.8.dylib  libinterp/.libs/liboctinterp_la-octave.o libinterp/operators/.libs/liboctinterp_la-op-b-b.o libinterp/operators/.libs/liboctinterp_la-op-b-bm.o libinterp/operators/.libs/liboctinterp_la-op-b-sbm.o libinterp/operators/.libs/liboctinterp_la-op-bm-b.o libinterp/operators/.libs/liboctinterp_la-op-bm-bm.o libinterp/operators/.libs/liboctinterp_la-op-bm-sbm.o libinterp/operators/.libs/liboctinterp_la-op-cdm-cdm.o libinterp/operators/.libs/liboctinterp_la-op-cdm-cm.o libinterp/operators/.libs/liboctinterp_la-op-cdm-cs.o libinterp/operators/.libs/liboctinterp_la-op-cdm-dm.o libinterp/operators/.libs/liboctinterp_la-op-cdm-m.o libinterp/operators/.libs/liboctinterp_la-op-cdm-s.o libinterp/operators/.libs/liboctinterp_la-op-cell.o libinterp/operators/.libs/liboctinterp_la-op-chm.o libinterp/operators/.libs/liboctinterp_la-op-class.o libinterp/operators/.libs/liboctinterp_la-op-cm-cdm.o libinterp/operators/.libs/liboctinterp_la-op-cm-cm.o libinterp/operators/.libs/liboctinterp_la-op-cm-cs.o libinterp/operators/.libs/liboctinterp_la-op-cm-dm.o libinterp/operators/.libs/liboctinterp_la-op-cm-m.o libinterp/operators/.libs/liboctinterp_la-op-cm-pm.o libinterp/operators/.libs/liboctinterp_la-op-cm-s.o libinterp/operators/.libs/liboctinterp_la-op-cm-scm.o libinterp/operators/.libs/liboctinterp_la-op-cm-sm.o libinterp/operators/.libs/liboctinterp_la-op-cs-cm.o libinterp/operators/.libs/liboctinterp_la-op-cs-cs.o libinterp/operators/.libs/liboctinterp_la-op-cs-m.o libinterp/operators/.libs/liboctinterp_la-op-cs-s.o libinterp/operators/.libs/liboctinterp_la-op-cs-scm.o libinterp/operators/.libs/liboctinterp_la-op-cs-sm.o libinterp/operators/.libs/liboctinterp_la-op-dm-cdm.o libinterp/operators/.libs/liboctinterp_la-op-dm-cm.o libinterp/operators/.libs/liboctinterp_la-op-dm-cs.o libinterp/operators/.libs/liboctinterp_la-op-dm-dm.o libinterp/operators/.libs/liboctinterp_la-op-dm-m.o libinterp/operators/.libs/liboctinterp_la-op-dm-s.o libinterp/operators/.libs/liboctinterp_la-op-dm-scm.o libinterp/operators/.libs/liboctinterp_la-op-dm-sm.o libinterp/operators/.libs/liboctinterp_la-op-fcdm-fcdm.o libinterp/operators/.libs/liboctinterp_la-op-fcdm-fcm.o libinterp/operators/.libs/liboctinterp_la-op-fcdm-fcs.o libinterp/operators/.libs/liboctinterp_la-op-fcdm-fdm.o libinterp/operators/.libs/liboctinterp_la-op-fcdm-fm.o libinterp/operators/.libs/liboctinterp_la-op-fcdm-fs.o libinterp/operators/.libs/liboctinterp_la-op-fcm-fcdm.o libinterp/operators/.libs/liboctinterp_la-op-fcm-fcm.o libinterp/operators/.libs/liboctinterp_la-op-fcm-fcs.o libinterp/operators/.libs/liboctinterp_la-op-fcm-fdm.o libinterp/operators/.libs/liboctinterp_la-op-fcm-fm.o libinterp/operators/.libs/liboctinterp_la-op-fcm-fs.o libinterp/operators/.libs/liboctinterp_la-op-fcm-pm.o libinterp/operators/.libs/liboctinterp_la-op-fcn.o libinterp/operators/.libs/liboctinterp_la-op-fcs-fcm.o libinterp/operators/.libs/liboctinterp_la-op-fcs-fcs.o libinterp/operators/.libs/liboctinterp_la-op-fcs-fm.o libinterp/operators/.libs/liboctinterp_la-op-fcs-fs.o libinterp/operators/.libs/liboctinterp_la-op-fdm-fcdm.o libinterp/operators/.libs/liboctinterp_la-op-fdm-fcm.o libinterp/operators/.libs/liboctinterp_la-op-fdm-fcs.o libinterp/operators/.libs/liboctinterp_la-op-fdm-fdm.o libinterp/operators/.libs/liboctinterp_la-op-fdm-fm.o libinterp/operators/.libs/liboctinterp_la-op-fdm-fs.o libinterp/operators/.libs/liboctinterp_la-op-fm-fcdm.o libinterp/operators/.libs/liboctinterp_la-op-fm-fcm.o libinterp/operators/.libs/liboctinterp_la-op-fm-fcs.o libinterp/operators/.libs/liboctinterp_la-op-fm-fdm.o libinterp/operators/.libs/liboctinterp_la-op-fm-fm.o libinterp/operators/.libs/liboctinterp_la-op-fm-fs.o libinterp/operators/.libs/liboctinterp_la-op-fm-pm.o libinterp/operators/.libs/liboctinterp_la-op-fs-fcm.o libinterp/operators/.libs/liboctinterp_la-op-fs-fcs.o libinterp/operators/.libs/liboctinterp_la-op-fs-fm.o libinterp/operators/.libs/liboctinterp_la-op-fs-fs.o libinterp/operators/.libs/liboctinterp_la-op-i16-i16.o libinterp/operators/.libs/liboctinterp_la-op-i32-i32.o libinterp/operators/.libs/liboctinterp_la-op-i64-i64.o libinterp/operators/.libs/liboctinterp_la-op-i8-i8.o libinterp/operators/.libs/liboctinterp_la-op-int-concat.o libinterp/operators/.libs/liboctinterp_la-op-m-cdm.o libinterp/operators/.libs/liboctinterp_la-op-m-cm.o libinterp/operators/.libs/liboctinterp_la-op-m-cs.o libinterp/operators/.libs/liboctinterp_la-op-m-dm.o libinterp/operators/.libs/liboctinterp_la-op-m-m.o libinterp/operators/.libs/liboctinterp_la-op-m-pm.o libinterp/operators/.libs/liboctinterp_la-op-m-s.o libinterp/operators/.libs/liboctinterp_la-op-m-scm.o libinterp/operators/.libs/liboctinterp_la-op-m-sm.o libinterp/operators/.libs/liboctinterp_la-op-mi.o libinterp/operators/.libs/liboctinterp_la-op-pm-cm.o libinterp/operators/.libs/liboctinterp_la-op-pm-fcm.o libinterp/operators/.libs/liboctinterp_la-op-pm-fm.o libinterp/operators/.libs/liboctinterp_la-op-pm-m.o libinterp/operators/.libs/liboctinterp_la-op-pm-pm.o libinterp/operators/.libs/liboctinterp_la-op-pm-scm.o libinterp/operators/.libs/liboctinterp_la-op-pm-sm.o libinterp/operators/.libs/liboctinterp_la-op-range.o libinterp/operators/.libs/liboctinterp_la-op-s-cm.o libinterp/operators/.libs/liboctinterp_la-op-s-cs.o libinterp/operators/.libs/liboctinterp_la-op-s-m.o libinterp/operators/.libs/liboctinterp_la-op-s-s.o libinterp/operators/.libs/liboctinterp_la-op-s-scm.o libinterp/operators/.libs/liboctinterp_la-op-s-sm.o libinterp/operators/.libs/liboctinterp_la-op-sbm-b.o libinterp/operators/.libs/liboctinterp_la-op-sbm-bm.o libinterp/operators/.libs/liboctinterp_la-op-sbm-sbm.o libinterp/operators/.libs/liboctinterp_la-op-scm-cm.o libinterp/operators/.libs/liboctinterp_la-op-scm-cs.o libinterp/operators/.libs/liboctinterp_la-op-scm-m.o libinterp/operators/.libs/liboctinterp_la-op-scm-s.o libinterp/operators/.libs/liboctinterp_la-op-scm-scm.o libinterp/operators/.libs/liboctinterp_la-op-scm-sm.o libinterp/operators/.libs/liboctinterp_la-op-sm-cm.o libinterp/operators/.libs/liboctinterp_la-op-sm-cs.o libinterp/operators/.libs/liboctinterp_la-op-sm-m.o libinterp/operators/.libs/liboctinterp_la-op-sm-s.o libinterp/operators/.libs/liboctinterp_la-op-sm-scm.o libinterp/operators/.libs/liboctinterp_la-op-sm-sm.o libinterp/operators/.libs/liboctinterp_la-op-str-m.o libinterp/operators/.libs/liboctinterp_la-op-str-s.o libinterp/operators/.libs/liboctinterp_la-op-str-str.o libinterp/operators/.libs/liboctinterp_la-op-struct.o libinterp/operators/.libs/liboctinterp_la-op-ui16-ui16.o libinterp/operators/.libs/liboctinterp_la-op-ui32-ui32.o libinterp/operators/.libs/liboctinterp_la-op-ui64-ui64.o libinterp/operators/.libs/liboctinterp_la-op-ui8-ui8.o libinterp/template-inst/.libs/liboctinterp_la-Array-tc.o libinterp/template-inst/.libs/liboctinterp_la-Array-jit.o libinterp/.libs/liboctinterp_la-build-env-features.o libinterp/.libs/liboctinterp_la-build-env.o libinterp/.libs/liboctinterp_la-builtins.o libinterp/corefcn/.libs/liboctinterp_la-oct-errno.o libinterp/.libs/liboctinterp_la-liboctinterp-build-info.o libinterp/operators/.libs/liboctinterp_la-ops.o   -Wl,-force_load,libinterp/octave-value/.libs/liboctave-value.a -Wl,-force_load,libinterp/parse-tree/.libs/libparse-tree.a -Wl,-force_load,libinterp/corefcn/.libs/libcorefcn.a  -L/usr/local/opt/hdf5/lib -L/usr/local/Cellar/graphicsmagick/1.3.35/lib -L/usr/local/Cellar/fftw/3.3.8_2/lib -L/usr/local/Cellar/arpack/3.7.0_5/libexec/lib -L/usr/local/Cellar/pcre/8.44/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/gettext/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/sundials27/lib -L/usr/local/opt/zlib/lib -L/usr/local/opt/qrupdate/lib liboctave/.libs/liboctave.dylib -L/usr/local/opt/openblas/lib -L/usr/local/Cellar/gcc/10.2.0/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0 -L/usr/local/Cellar/gcc/10.2.0/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0/../../.. -L/usr/local/opt/freetype/lib -lhdf5 /usr/local/Cellar/graphicsmagick/1.3.35/lib/libGraphicsMagick++.dylib /usr/local/Cellar/graphicsmagick/1.3.35/lib/libGraphicsMagick.dylib -llcms2 -lbz2 -lltdl -lpthread -lz -framework OpenGL -lfontconfig -lfreetype -framework Carbon -lgl2ps -lcurl -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -lsuitesparseconfig /usr/local/Cellar/arpack/3.7.0_5/libexec/lib/libarpack.dylib -lqrupdate -lfftw3_threads -lfftw3 -lfftw3f_threads -lfftw3f -lopenblas -lreadline -lncurses -lpcre -ldl -lgfortran -lquadmath -liconv -lm  -pthread -g -O2 -F/usr/local/opt/qt5/lib -Wl,-framework -Wl,CoreFoundation   -pthread -framework OpenGL -framework Carbon -install_name  /usr/local/bpabbott/octave/lib/octave/7.0.0/liboctinterp.8.dylib -compatibility_version 9 -current_version 9.0 -Wl,-single_module
Undefined symbols for architecture x86_64:
  "octave::math::sparse_qr<SparseMatrix>::sparse_qr(SparseMatrix const&, int)", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseMatrix>::~sparse_qr()", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseComplexMatrix>::sparse_qr(SparseComplexMatrix const&, int)", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseComplexMatrix>::~sparse_qr()", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseMatrix>::C(Matrix const&) const", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseMatrix>::Q() const", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseMatrix>::R(bool) const", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseComplexMatrix>::C(ComplexMatrix const&) const", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseComplexMatrix>::Q() const", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
  "octave::math::sparse_qr<SparseComplexMatrix>::R(bool) const", referenced from:
      Fqr(octave_value_list const&, int) in libcorefcn.a(libcorefcn_la-qr.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: * [libinterp/liboctinterp.la] Error 1
make[1]: * [all-recursive] Error 1

Ben Abbott <bpabbott>
Group Member
Thu 21 Jan 2021 07:14:48 AM UTC, comment #19: 

@Ben: This page is from a gcc perspective:
https://gcc.gnu.org/wiki/Visibility

I don't know if there is a similar introduction for visibility with Apple clang. But the general concept should be the same across compilers/vendors on POSIX platforms.

Markus Mützel <mmuetzel>
Group administrator
Thu 21 Jan 2021 04:18:47 AM UTC, comment #18: 

@Carlo, as I have time I'll revert and try building after revering cd6b616b36a8 and all changes since.

@Markus, I'll also give you patch a try. Regarding the visibility attributes, can you give a link explaining what this does?

Ben Abbott <bpabbott>
Group Member
Wed 20 Jan 2021 05:26:21 PM UTC, comment #17: 

The attached patch should allow to optionally disable compiling and linking the libraries with visibility attributes.

After applying it, run the bootstrap script and configure with "--disable-lib-visibility".

It would still be good if someone could check what we'd need to change to get Octave to compile with visibility attributes on Mac.

(file #50756)

Markus Mützel <mmuetzel>
Group administrator
Wed 20 Jan 2021 03:20:52 PM UTC, comment #16: 

@cdf: That'll probably be the change immediately before this one:
https://hg.savannah.gnu.org/hgweb/octave/rev/cd6b616b36a8

Markus Mützel <mmuetzel>
Group administrator
Wed 20 Jan 2021 03:07:48 PM UTC, comment #15: 

@Ben

Did you try to find out what is the latest chengeset that builds correctly on macos?


Carlo de Falco <cdf>
Group Member
Wed 20 Jan 2021 10:18:58 AM UTC, comment #14: 

Re-titling report to better describe the issue.

Markus Mützel <mmuetzel>
Group administrator
Fri 08 Jan 2021 10:40:07 AM UTC, comment #13: 

Like I already wrote, I can't really solve this because I don't have a Mac.

Some general advice for someone motivated:
For me, it worked best to try and tackle the missing symbols one at a time.
E.g. for the missing symbol "_set_liboctave_warning_with_id_handler":

  1. Try and find where in the sources that symbol should be defined. For that symbol, it is most likely a C mangled version (leading underscore) of the function "set_liboctave_warning_with_id_handler" defined in "liboctave/util/lo-error.cc".
  2. Check which symbols are exported by that compile unit. I don't know the naming conventions on Mac or whether it has "nm" at all. On Linux, I'd try:


nm -C liboctave/util/.libs/libutil_la-lo-error.o | grep "set_liboctave_warning_with_id_handler"

  1. If the symbol is exported from that compile unit, check if the name is mangled as expected:


nm liboctave/util/.libs/libutil_la-lo-error.o | grep "set_liboctave_warning_with_id_handler"

  1. If this is also ok, check if it is exported from the corresponding library. On Linux for that file, that would be:


nm -C liboctave/.libs/liboctave.so | grep "set_liboctave_warning_with_id_handler"


The symbol must be in the exported symbol table of that library. With "nm" that is indicated by e.g. "T" or "W" before the symbol name.

Depending on which step failed, try and find out why that is...

If there is a pattern, it might make sense to apply the solution to similar symbols.

Good luck hunting down the issues.

If there are changesets that allow linking on MacOS, I'm happy to check if those would be compatible with gcc and clang on Linux and possibly also with Windows targets.

Markus Mützel <mmuetzel>
Group administrator
Fri 08 Jan 2021 04:19:09 AM UTC, comment #12: 

I just tried building


$ hg id
62198e9d525f tip @


On macos 11.1

I attach the configure options I used (file #50681),
and the output of configure (file #50680) and of make
(file #50682)

Carlo de Falco <cdf>
Group Member
Thu 07 Jan 2021 11:45:03 PM UTC, comment #11: 

@Carlo,

I'm still running 10.15.7. I can upgrade to 11, but haven't done so yet.

Ben Abbott <bpabbott>
Group Member
Thu 07 Jan 2021 11:43:08 PM UTC, comment #10: 

I've run configure and attached the result

(file #50676)

Ben Abbott <bpabbott>
Group Member
Thu 07 Jan 2021 04:57:23 PM UTC, comment #9: 

I may help with testing on macos, but have upgraded to macos 11.1 so my results could be different from those reported by Ben

Carlo de Falco <cdf>
Group Member
Thu 07 Jan 2021 04:07:23 PM UTC, comment #8: 

These visibility attributes aren't very well documented. The behavior seems to be very dependent on platform and compiler vendor. Even different compiler flags seem to lead to different results.
Getting this somewhat right seems to need a lot of experimentation.
I don't have access to an Apple computer. So unless there is a developer on MacOS who is willing to invest some time into this, we are left with two options that I can think of:

  1. Leave the MacOS builds broken to build up some pressure to hopefully motivate someone to look into this on MacOS.
  2. Don't build with visibility settings on MacOS. (The patch from comment #1 is not complete for this.)
Markus Mützel <mmuetzel>
Group administrator
Thu 07 Jan 2021 03:55:22 PM UTC, comment #7: 

On macOS 10.15.7

g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.28)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Ben Abbott <bpabbott>
Group Member
Wed 06 Jan 2021 09:55:37 PM UTC, comment #6: 

I tried googling "apple clang function visibility" and came up with a few hits which look like Apple's clang is different from both regular clang and from gcc.  This might be annoying to fix.

Rik <rik5>
Group administrator
Wed 06 Jan 2021 12:31:36 PM UTC, comment #5: 

Could you please upload a complete build log (including any potential warnings during compilation)?
Is the `g++` you are using actually a compiler from GCC? Or is it a link to `clang++`?
What does `g++ --version` return?

Markus Mützel <mmuetzel>
Group administrator
Tue 05 Jan 2021 09:19:13 PM UTC, comment #4: 

My tip is now ...

$ hg tip
changeset:   29262:7e378993e8fa
bookmark:    @
tag:         tip
parent:      29260:18ad3c01fc2a
parent:      29261:f36ca61488e0
user:        Markus Mützel <markus.muetzel@gmx.de>
date:        Tue Jan 05 15:54:22 2021 +0100
summary:     maint: merge stable to default.

I"ve attached the result of bulging.

(file #50664)

Ben Abbott <bpabbott>
Group Member
Tue 05 Jan 2021 03:43:24 PM UTC, comment #3: 

@Markus
Typically macOS (BSD variant) is able to build what Linux is able to build. There are occasionally some differences with Apple's variant of clang.

After updating to fdfd874293f6, the problem persists. I've pulled the more recent changes and am compiling now.


Ben Abbott <bpabbott>
Group Member
Tue 05 Jan 2021 12:21:22 AM UTC, comment #2: 

"If you'd prefer to be able to compile without too much effort, you could try with the attached patch which should revert the visibility settings.
(Maybe we should do that on all platforms we haven't tested.)"

I'd suggest that we just keep moving forward.  Keep testing, more users will try it on various platforms and report errors, we fix those and keep going.  Eventually the error reports will dwindle to a trickle.  I imagine that the number of compiler/OS combinations that we need to support is actually fairly small: Linux (gcc & clang), Windows (gcc through MXE Octave), MacOS (clang & gcc).  We already don't compile well with Intel MKL compiler so we can probably skip that.  And other systems, like Solaris, are pretty niche.

Rik <rik5>
Group administrator
Mon 04 Jan 2021 09:01:51 PM UTC, comment #1: 

Thanks for testing on Mac OS.
While I was hoping that the changes for patch #8919 would work on that platform if the code compiles on Linux, I wasn't very confident that would actually work. (Especially, after it turned out that different compilers interpreted the visibility attributes differently on the same platform.)

There have been a few changes after that changeset with fixes for clang on Linux.
Could you please try with a newer revision (at least d83ae0145030 or newer)?
This will probably not fix all of the missing symbols. But maybe some.

Do you have pointers to how "visibility" or "exported functions" work in general on MacOS? At least Windows seems to have quite a different concept from Linux in this respect...

If you'd prefer to be able to compile without too much effort, you could try with the attached patch which should revert the visibility settings.
(Maybe we should do that on all platforms we haven't tested.)

(file #50649)

Markus Mützel <mmuetzel>
Group administrator
Mon 04 Jan 2021 04:53:54 PM UTC, original submission:  

$ hg tip
changeset:   29244:d1473e75d7d6
bookmark:    @
tag:         tip
user:        Markus Mützel <markus.muetzel@gmx.de>
date:        Fri Jan 01 17:33:04 2021 +0100
summary:     lo-utils: Export template instantiations (patch #8919).

I've attached how make ends (it is long).

I'm happy to revert suggested changes to track the problem down.

Ben Abbott <bpabbott>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #52435:  bug59820-visibility-cdef-classes.patch added by mmuetzel (4KiB - application/octet-stream)
file #50682:  make-macos.log.zip added by cdf (119KiB - application/zip)
file #50680:  config-macos.log added by cdf (64KiB - application/octet-stream)
file #50681:  buildcommand.sh added by cdf (2KiB - application/x-sh)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by siko1056 (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by cdf (Posted a comment)
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by bpabbott (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.

    Only group members can vote.

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-12-19 mmuetzel StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2021-12-18 mmuetzel StatusNeed Info In Progress
    2021-12-15 mmuetzel StatusIn Progress Need Info
    2021-12-05 mmuetzel Attached File- Added bug59820-visibility-cdef-classes.patch, #52435
    2021-11-17 siko1056 Releasedev 7.0.90
    2021-05-12 mmuetzel StatusReady For Test In Progress
    2021-05-11 mmuetzel StatusConfirmed Ready For Test
    2021-03-09 rik5 Carbon-CopyRemoved 72865 -
    2021-03-09 rik5 Priority5 - Normal 3 - Low
        StatusNone Confirmed
    2021-01-20 mmuetzel Attached File- Added bug59820_visibility_optional.patch, #50756
    2021-01-20 mmuetzel Summarybuild fails on macOS build fails on macOS with visibility settings
    2021-01-08 cdf Attached File- Added make-macos.log.zip, #50682
    2021-01-08 cdf Attached File- Added config-macos.log, #50680
        Attached File- Added buildcommand.sh, #50681
    2021-01-08 cdf Attached File#50678 Removed
    2021-01-08 cdf Attached File#50677 Removed
    2021-01-08 cdf Attached File- Added make.log, #50678
    2021-01-08 cdf Attached File- Added buildcommand.sh, #50677
    2021-01-07 bpabbott Attached File- Added build-failure-macOS-configure-2021.01.07.txt, #50676
    2021-01-06 mmuetzel CategoryNone Configuration and Build System
    2021-01-05 bpabbott Attached File- Added build_failure_macOS-2020.01.05.txt, #50664
    2021-01-04 mmuetzel Attached File- Added bug59820_revert_visibility.patch, #50649
    2021-01-04 bpabbott Attached File- Added build-failure-macOS-2020.10.04.txt, #50646

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code