patchGNU Octave - Patches: patch #8919, Start of patch to enable...

 
 

patch #8919: Start of patch to enable visibility attributes for GCC in build system

Submitted by:  Rik <rik5>
Submitted on:  Fri 26 Feb 2016 05:32:15 PM UTC
 
Category:  Core : other Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Fri 22 Jan 2021 04:37:06 PM UTC, comment #36: 

It is probably ok to track remaining issues in separate reports.

Closing as done.

Markus Mützel <mmuetzel>
Project Member
Sat 09 Jan 2021 11:05:38 AM UTC, comment #35: 

Nevermind, I mis-read the error message. Array<short> is explicitly instantiated correctly in Array-s.cc. So it cannot be instantiated again...

No issue here.

Markus Mützel <mmuetzel>
Project Member
Thu 07 Jan 2021 08:50:12 PM UTC, comment #34: 

The Windows build failed with a different error than I expected.

I pushed a change here that also instantiates more integer types in Array<T>:
https://hg.savannah.gnu.org/hgweb/octave/rev/e4c152e827aa

With that change Octave builds for me with gcc and clang on Ubuntu and for Windows.

Explicitly instantiating Array<short> failed with an error about it being instantiated implicitly before.
If I understand the Array<T> template class correctly, that might be an issue. Is that correct?

Markus Mützel <mmuetzel>
Project Member
Thu 07 Jan 2021 06:54:54 PM UTC, comment #33: 

Can't say what effect the extra patch would have on other operating systems, but it does fix the issue for me on Linux.

Rik <rik5>
Project Administrator
Thu 07 Jan 2021 05:41:43 PM UTC, comment #32: 

Sorry. I didn't realize that I had some local changes in the source tree I built from.
With a clean tree, I do see the same linking error you reported.

I'm looking at the changes now to find out which made the difference. It looks like the attached patch does it here.
I haven't yet checked whether these changes would be save for clang and Windows. (I'd guess they would break the Windows builds.)

(file #50673)

Markus Mützel <mmuetzel>
Project Member
Thu 07 Jan 2021 05:25:16 PM UTC, comment #31: 

What version of g++ are you using?  It is possible that this is a bug in g++ or the linker.

Rik <rik5>
Project Administrator
Thu 07 Jan 2021 04:29:07 PM UTC, comment #30: 

I tried to reproduce by configuring with the following:

../configure CFLAGS="-O0 -pipe -ggdb3" CXXFLAGS="-O0 -pipe -ggdb3" FFLAGS="-O0 -pipe -ggdb3" CPPFLAGS="-I/usr/include/hdf5/serial -I/usr/include/suitesparse" LDFLAGS="-L/usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/hdf5/serial" --prefix=${HOME}/usr

Compilation and linking works without error here.

Markus Mützel <mmuetzel>
Project Member
Wed 06 Jan 2021 10:27:43 PM UTC, comment #29: 

I'm getting an error during final linking that is probably related to the visibility changes.  The error is

libinterp/.libs/liboctinterp.so: undefined reference to `Array<idx_vector>::operator()(long) const'

This happens when I use compilation flags "-O0 -pipe".  It disappears if I use an optimization level of 1 or 2.  Perhaps this is a g++ bug as well.  My version is "g++ (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0".

It's annoying because the flags that I typically run for debugging are "-ggdb3 -O0 -pipe" because I find that the optimization makes it harder to walk through code in gdb.

Rik <rik5>
Project Administrator
Sat 02 Jan 2021 06:37:08 PM UTC, comment #28: 

After the last few changes, the buildbots using clang seem to be happy again.

I couldn't find a setup that was working without clang or gcc moaning. So I used different code for each of them.
That isn't ideal. But I hope it is ok.
I'd be happy if someone could show how that works for both compilers without having dedicated code for each.

Markus Mützel <mmuetzel>
Project Member
Fri 01 Jan 2021 04:24:47 PM UTC, comment #27: 

When I started working on this again, I was expecting (or hoping) that Windows would be the only "odd-ball" here. I hoped that the other platforms would behave quite uniformly.
It turns out this is not the case: Even different compilers (gcc and clang) for the same platform (Linux) interpret the visibility attributes differently.

Maybe we should use visibility more conservatively or make it optional. But it is also possible to wait for users on different platforms (darwin?) to report if they see issues.

Meanwhile, I pushed a partial fix for compiling with clang here:
https://hg.savannah.gnu.org/hgweb/octave/rev/f207504ae98d

This still won't lead to a successful build with clang. But the linker will complain about less missing symbols...

It takes some time to find something that works with gcc and with clang and doesn't break the Windows build. And sometimes it is not clear to me why something breaks. So, I'll try and push smaller changes that seem to be working...

Markus Mützel <mmuetzel>
Project Member
Thu 31 Dec 2020 06:56:58 PM UTC, comment #26: 

With the attached patch, Octave builds with clang 11.0.0-2 on Ubuntu for me.
But at the same time, I see a lot of warnings when compiling with gcc 10.2.0.
Oh why can't the compilers just agree on how this should be working?!

I haven't tested if this will work for Windows yet...

(file #50591)

Markus Mützel <mmuetzel>
Project Member
Thu 31 Dec 2020 03:44:38 PM UTC, comment #25: 

Quite the impressively long changeset!  I'm building my local version of Octave now, but as I use gcc this is likely to pass.

Rik <rik5>
Project Administrator
Thu 31 Dec 2020 02:17:00 PM UTC, comment #24: 

Looks like clang isn't happy with these changes:
http://buildbot.octave.org:8010/#/builders/32/builds/297/steps/6/logs/stdio
I've only tested with gcc until now...
I'll try to have a look at it.

Markus Mützel <mmuetzel>
Project Member
Thu 31 Dec 2020 01:09:31 PM UTC, comment #23: 

While going through the changes, I found I few symbols that haven't been marked for export/import yet.
With those added, the test suite passes on Linux and Windows. So I reconsidered again and pushed the changes to the default branch.
Probably to many to list them all here.
First:
https://hg.savannah.gnu.org/hgweb/octave/rev/5aa787452544
Last:
https://hg.savannah.gnu.org/hgweb/octave/rev/0a6ed9dcd601

I didn't go meticulously through every single line of code. So it is likely that there are some symbols missing still. But it is probably good enough for a start...

Marking as ready for test.

Markus Mützel <mmuetzel>
Project Member
Wed 30 Dec 2020 08:46:49 PM UTC, comment #22: 

Thanks for the explanation.

John W. Eaton <jwe>
Project Administrator
Wed 30 Dec 2020 07:59:38 PM UTC, comment #21: 

Re comment #20: That would happen if we used only one macro for setting the visibility attribute in all libraries.
For Windows targets, those attributes can be set to either "dllexport" or "dllimport" the respective symbols. If we used only one macro, we'd set it to always "dllexport". That means, we'd export the symbols whenever the respective headers are included in each library.
IIUC, a function must be defined in a library when the symbol has the "dllexport" attribute. It must not be defined in the same library (or program) if it has the the "dllimport" attribute.
With that, we need to have separate API macros for each library.
There are a few symbols (specializations/instantiations of the Array template class) that are exported by the same header/files from both liboctave and liboctinterp. All other symbols seem to be defined in headers exclusive to their respective library. I think I found a solution for that.

Many classdef related BISTs are failing on Windows with the changes I am currently working with. Atm, it's not clear to me why.
So, I no longer plan on pushing them as they are. Instead, I'll likely upload a series of patches here after I came around to cleaning them up.

Markus Mützel <mmuetzel>
Project Member
Wed 30 Dec 2020 03:11:42 PM UTC, comment #20: 

"I'm no longer sure it is good practice to export the same symbols from multiple libraries."

How would that happen?  We shouldn't have the same symbol defined in two different libraries.  Currently, we really just have two libraries that export symbols, liboctave and liboctinterp and the sets of symbols they define should not overlap.

John W. Eaton <jwe>
Project Administrator
Wed 30 Dec 2020 11:01:17 AM UTC, comment #19: 

I managed to get Octave to compile and link with "selective visibility" for Linux and Windows.
I'm currently trying to clean the changes up and will probably push a series of changes later today or tomorrow if no one objects.

Markus Mützel <mmuetzel>
Project Member
Sat 26 Dec 2020 07:53:15 PM UTC, comment #18: 

I tried to compile with visibility attributes for Windows using the attached "part4".

But it looks like there is a compatibility issue with how we use (inline) definitions in headers and the dllexport-dllimport mechanism used on Windows: Symbols marked with the "dllimport" attribute cannot have definitions in the same compilation unit. [1]
GCC fails with a very similar error in that case ("function X definition is marked dllimport").

That means, we'd need to restrict us to declarations in headers we'd like to use for symbol import.
We are probably using definitions in header file because we'd like to give the compiler the opportunity to inline those functions.
But to be able to use mark symbols as dllimports, we'd need to separate declaration and definition (or use separate headers for import?). However, this might lead to the compiler producing less efficient instructions.

With the changes from "part5" compilation succeeds. But linking liboctinterp-8.dll fails with a whole lot of errors similar to this one:

/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov-bool.cc:200: undefined reference to `double octave::read_value<double>(std::istream&)'

But that symbol is exported by liboctave-8.dll:

$ nm -C ./tmp-default-octave/octave-7.0.0/.build/liboctave/.libs/liboctave-8.dll | grep "octave::read_value<double>"
000000006ceb0910 T double octave::read_value<double>(std::istream&)

I've currently no idea how to fix that.

(file #50572, file #50573)

Markus Mützel <mmuetzel>
Project Member
Sat 26 Dec 2020 07:41:56 PM UTC, comment #17: 

After reading up on this a little more, I changed my mind about using only one single macro for all libraries we build for Octave.
I'm no longer sure it is good practice to export the same symbols from multiple libraries.

I tried to reproduce what jwe has done with his patches while maintaining the different macros for the library APIs. "part2" is basically equivalent to jwe's "patch-1" (but I split a part that isn't directly related to visibility into "part1" and added a few more API flags).
"part3" is an alternative approach to jwe's "patch-2".
With these patches, I can compile without errors on Linux.

But I'm struggling when it comes to doing something equivalent for Windows. More in a follow-up comment.

[1]: https://docs.microsoft.com/en-us/troubleshoot/cpp/c2491-define-data-member-dllimport

(file #50569, file #50570, file #50571)

Markus Mützel <mmuetzel>
Project Member
Wed 23 Dec 2020 05:41:07 PM UTC, comment #16: 

This was probably the reason why there were separate macros for each library. For the win32 target, we need separate definitions for export and import of the symbols.
This seems actually to be platform specific (not compiler specific):
https://gcc.gnu.org/wiki/Visibility#How_to_use_the_new_C.2B-.2B-_visibility_support

I currently trying with this change:

diff -r 636c49a35d2e -r 653683b44222 configure.ac
--- a/configure.ac        Wed Dec 23 13:30:26 2020 +0100
+++ b/configure.ac        Wed Dec 23 18:37:58 2020 +0100
@@ -2488,7 +2488,6 @@
         else
           JAVA_CPPFLAGS="-I\"${JAVA_HOME}/include\" -I\"${JAVA_HOME}/include/win32\""
         fi
-        LDFLAGS="$LDFLAGS -Wl,--export-all-symbols"
       fi
       AC_DEFINE(HAVE_JAVA, 1,
         [Define to 1 if Java is available and is at least version 1.5])
diff -r 636c49a35d2e -r 653683b44222 oct-conf-post.in.h
--- a/oct-conf-post.in.h        Wed Dec 23 13:30:26 2020 +0100
+++ b/oct-conf-post.in.h        Wed Dec 23 18:37:58 2020 +0100
@@ -173,9 +173,16 @@
 /* FIXME: GCC supports visibility attributes as well, even using the
    same __declspec declaration if desired.  The build system should be
    extended to support GCC and visibility attributes.  */
-#if defined (_MSC_VER)
-#  define OCTAVE_EXPORT __declspec(dllexport)
-#  define OCTAVE_IMPORT __declspec(dllimport)
+#if defined (_WIN32) || defined (__CYGWIN__)
+#  if defined (__GNUC__)
+/* GCC */
+#    define OCTAVE_EXPORT __attribute__ ((dllexport))
+#    define OCTAVE_IMPORT __attribute__ ((dllimport))
+#  else
+/* MSVC */
+#    define OCTAVE_EXPORT __declspec(dllexport)
+#    define OCTAVE_IMPORT __declspec(dllimport)
+#  endif
 #else
    /* All other compilers, at least for now. */
 #  define OCTAVE_EXPORT __attribute__ ((visibility ("default")))

But this will probably fail because we'd need to define OCTAVE_API to OCTAVE_IMPORT for the headers belonging to libraries we currently don't compile...

Markus Mützel <mmuetzel>
Project Member
Wed 23 Dec 2020 04:59:42 PM UTC, comment #15: 

Maybe, we'd need to add "__declspec (dllexport)" to OCTAVE_API when building the library?
Does that also mean, we'd need to set it to ""__declspec (dllimport)" when we are linking to it?

https://docs.microsoft.com/en-us/cpp/cpp/dllexport-dllimport?view=msvc-160

Markus Mützel <mmuetzel>
Project Member
Wed 23 Dec 2020 04:42:38 PM UTC, comment #14: 

Reading back in bug #39454, there was already some awareness then that it would rather be a temporary fix. So jwe's comment #12 is exactly right.
Well, here 'temporary' turns out to be 6.5 years.

I also read back in the discussion referenced in comment #10 that llvm required the offending flag as well.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 23 Dec 2020 03:51:28 PM UTC, comment #13: 

@jwe: I tried doing that. But without that flag, linking the .oct files in dldfcn fails.
E.g.:

libtool: link: x86_64-w64-mingw32-g++ -shared -nostdlib /home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/lib/../lib/dllcrt2.o /home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/lib/gcc/x86_64-w64-mingw32/10.2.0/crtbegin.o  libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o   -L/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/.build/liboctave/.libs -L/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/x86_64-w64-mingw32/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/x86_64-w64-mingw32/qt5/lib libinterp/.libs/liboctinterp.dll.a -L/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/lib/gcc/x86_64-w64-mingw32/10.2.0 -L/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/mingw/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/.build/liboctave/external/blas-xtra/.libs -L/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/x86_64-w64-mingw32/lib/gcc/x86_64-w64-mingw32/10.2.0 liboctave/.libs/liboctave.dll.a -lqhull -lshlwapi -lpsapi -lgdi32 -L/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/lib/../lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/lib /home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/lib/gcc/x86_64-w64-mingw32/10.2.0/libstdc++.dll.a /home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/x86_64-w64-mingw32/lib/gcc/x86_64-w64-mingw32/10.2.0/libgomp.dll.a -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt /home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/lib/gcc/x86_64-w64-mingw32/10.2.0/crtend.o  -fopenmp -g -O2 -Wl,-rpath-link -Wl,/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/x86_64-w64-mingw32/lib -Wl,-rpath-link -Wl,/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/x86_64-w64-mingw32/lib   -fopenmp -pthread -o libinterp/dldfcn/.libs/__delaunayn__.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker libinterp/dldfcn/.libs/__delaunayn__.dll.a
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o:/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/dldfcn/__delaunayn__.cc:81: undefined reference to `warning(char const*, ...)'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o:/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/dldfcn/__delaunayn__.cc:101: undefined reference to `check_version(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `G__delaunayn__':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/dldfcn/__delaunayn__.cc:101: undefined reference to `octave_dld_function::create(octave_value_list (*)(octave_value_list const&, int), octave::dynamic_library const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `F__delaunayn__(octave_value_list const&, int)':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/dldfcn/__delaunayn__.cc:114: undefined reference to `print_usage()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/dldfcn/__delaunayn__.cc:118: undefined reference to `octave_value::octave_value(double)'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `octave_value::~octave_value()':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:336: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `F__delaunayn__(octave_value_list const&, int)':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/dldfcn/__delaunayn__.cc:149: undefined reference to `error(char const*, ...)'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `octave_value::octave_value()':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:167: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `octave_value::~octave_value()':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:336: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `F__delaunayn__(octave_value_list const&, int)':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/dldfcn/__delaunayn__.cc:219: undefined reference to `octave_value::octave_value(Matrix const&, MatrixType const&)'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `octave_value::operator=(octave_value&&)':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:393: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `octave_value::~octave_value()':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:336: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:336: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `F__delaunayn__(octave_value_list const&, int)':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/dldfcn/__delaunayn__.cc:229: undefined reference to `octave_value::octave_value(RowVector const&)'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `octave_value::octave_value()':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:167: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `octave_value::~octave_value()':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:336: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `octave_value::operator=(octave_value&&)':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:393: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `octave_value::~octave_value()':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:336: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:336: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o:/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:393: more undefined references to `octave_value::nil_rep()' follow
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `F__delaunayn__(octave_value_list const&, int)':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/dldfcn/__delaunayn__.cc:200: undefined reference to `error(char const*, ...)'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o:/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/dldfcn/__delaunayn__.cc:93: undefined reference to `error(char const*, ...)'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `F__delaunayn__(octave_value_list const&, int)':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/dldfcn/__delaunayn__.cc:172: undefined reference to `error(char const*, ...)'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/dldfcn/__delaunayn__.cc:183: undefined reference to `error(char const*, ...)'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `octave_value::~octave_value()':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:336: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `octave_value::~octave_value()':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:336: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:336: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `octave_value::operator=(octave_value&&)':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:393: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o: in function `octave_value::operator=(octave_value const&)':
/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:375: undefined reference to `octave_value::nil_rep()'
/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/bin/x86_64-w64-mingw32-ld: libinterp/dldfcn/.libs/__delaunayn___la-__delaunayn__.o:/home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov.h:336: more undefined references to `octave_value::nil_rep()' follow
collect2: error: ld returned 1 exit status
make[5]: *** [Makefile:12528: libinterp/dldfcn/__delaunayn__.la] Error 1

If I take the liboctinterp-8.dll that is already built at that point and look at the symbols it exports, there are only the following:

Java_org_octave_OctaveReference_doFinalize
Java_org_octave_Octave_call
Java_org_octave_Octave_doEvalString
Java_org_octave_Octave_doInvoke
Java_org_octave_Octave_needThreadedInvokation

What happened to the other symbols we marked for export?

Markus Mützel <mmuetzel>
Project Member
Wed 23 Dec 2020 03:24:27 PM UTC, comment #12: 

Markus: I think we should just try removing that flag and see what happens.  Then, if some necessary symbols are missing, export them as needed.  My guess is that adding the export all symbols option was done because it was easier than tackling the symbol export problem properly.

John W. Eaton <jwe>
Project Administrator
Wed 23 Dec 2020 01:43:18 PM UTC, comment #11: 

It's a long time ago so my recollection of it is hazy, but AFAIR there were issues with exporting symbols other than Java ones that were fixed by that cset.
Perhaps since then things have changed (mind you: for better or for worse), who knows, but in the mean time there have been no reasons to revisit this - until now, of course :-)

Philip Nienhuis <philipnienhuis>
Project Member
Wed 23 Dec 2020 01:30:49 PM UTC, comment #10: 

Answer probably in this thread:
https://lists.gnu.org/archive/html/octave-maintainers/2013-07/msg00007.html

Philip
(lousy Internet options ATM, sorry to be of limited help)

Anonymous
Wed 23 Dec 2020 11:16:58 AM UTC, comment #9: 

Compilation of Octave with these patches with MXE Octave went smoothly.
But looking at the symbols that are exported from liboctave-8.dll, there seem to be quite a few which are instantiations of standard library templates(?). E.g. (among a lot of other similar ones):

_ZNSt10unique_ptrIA_10idx_vectorSt14default_deleteIS1_EED1Ev
_ZNSt10unique_ptrIA_5ArrayIxESt14default_deleteIS2_EED1Ev
_ZNSt10unique_ptrIA_NSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt14default_deleteIS6_EED1Ev
_ZNSt10unique_ptrIN10idx_vector14idx_vector_repESt14default_deleteIS1_EED1Ev
_ZNSt10unique_ptrIN6octave16action_container4elemESt14default_deleteIS2_EED1Ev
_ZNSt11_Deque_baseI14sortrows_run_tSaIS0_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseI14sortrows_run_tSaIS0_EED2Ev
_ZNSt11_Deque_baseIPN6octave16action_container4elemESaIS3_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseIPN6octave16action_container4elemESaIS3_EED2Ev
_ZNSt11_Deque_baseISt4pairIPK10octave_intIaExESaIS5_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPK10octave_intIaExESaIS5_EED2Ev
_ZNSt11_Deque_baseISt4pairIPK10octave_intIhExESaIS5_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPK10octave_intIhExESaIS5_EED2Ev
_ZNSt11_Deque_baseISt4pairIPK10octave_intIiExESaIS5_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPK10octave_intIiExESaIS5_EED2Ev
_ZNSt11_Deque_baseISt4pairIPK10octave_intIjExESaIS5_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPK10octave_intIjExESaIS5_EED2Ev
_ZNSt11_Deque_baseISt4pairIPK10octave_intIsExESaIS5_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPK10octave_intIsExESaIS5_EED2Ev
_ZNSt11_Deque_baseISt4pairIPK10octave_intItExESaIS5_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPK10octave_intItExESaIS5_EED2Ev
_ZNSt11_Deque_baseISt4pairIPK10octave_intIxExESaIS5_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPK10octave_intIxExESaIS5_EED2Ev
_ZNSt11_Deque_baseISt4pairIPK10octave_intIyExESaIS5_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPK10octave_intIyExESaIS5_EED2Ev
_ZNSt11_Deque_baseISt4pairIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEExESaIS9_EED2Ev
_ZNSt11_Deque_baseISt4pairIPKP22octave_idx_vector_sortxESaIS5_EED2Ev
_ZNSt11_Deque_baseISt4pairIPKP23octave_sparse_sort_idxlxESaIS5_EED2Ev
_ZNSt11_Deque_baseISt4pairIPKSt7complexIdExESaIS5_EED2Ev
_ZNSt11_Deque_baseISt4pairIPKSt7complexIfExESaIS5_EED2Ev
_ZNSt11_Deque_baseISt4pairIPKbxESaIS3_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPKbxESaIS3_EED2Ev
_ZNSt11_Deque_baseISt4pairIPKcxESaIS3_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPKcxESaIS3_EED2Ev
_ZNSt11_Deque_baseISt4pairIPKdxESaIS3_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPKdxESaIS3_EED2Ev
_ZNSt11_Deque_baseISt4pairIPKfxESaIS3_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPKfxESaIS3_EED2Ev
_ZNSt11_Deque_baseISt4pairIPKixESaIS3_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPKixESaIS3_EED2Ev
_ZNSt11_Deque_baseISt4pairIPKlxESaIS3_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPKlxESaIS3_EED2Ev
_ZNSt11_Deque_baseISt4pairIPKsxESaIS3_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPKsxESaIS3_EED2Ev
_ZNSt11_Deque_baseISt4pairIPKxxESaIS3_EE17_M_initialize_mapEy
_ZNSt11_Deque_baseISt4pairIPKxxESaIS3_EED2Ev
_ZNSt11_Deque_baseIySaIyEED2Ev

Also the symbols from gnulib seem to be exported still.

This might be because we are linking with `-Wl,--export-all-symbols` for Windows (mingw). It looks like this overrides the visibility flags set for compilation.

That flag was added in this changeset for Java support:
https://hg.savannah.gnu.org/hgweb/octave/rev/db4453f40550

What was broken before this flag was added?
Could we link without the `--export-all-symbols` flag?

Markus Mützel <mmuetzel>
Project Member
Tue 22 Dec 2020 02:06:35 PM UTC, comment #8: 

With the attached patch on top of jwe's two patches, `make check` passes for me.

(file #50543)

Markus Mützel <mmuetzel>
Project Member
Tue 22 Dec 2020 11:53:23 AM UTC, comment #7: 

I applied the two patches on top of hg id 6e031c8ed59c, ran bootstrap, configure and make. Compilation and linking was successful.
But `make check` stops with this error:

  audio/@audioplayer/audioplayer.m .............................../home/osboxes/Documents/Repositories/Octave/octave-1/.build/libinterp/dldfcn/audiodevinfo.oct: failed to load: /home/osboxes/Documents/Repositories/Octave/octave-1/.build/libinterp/dldfcn/audiodevinfo.oct: undefined symbol: _ZN6octave17__get_type_info__ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

Markus Mützel <mmuetzel>
Project Member
Tue 22 Dec 2020 11:03:26 AM UTC, comment #6: 

What would be the advantage of having separate API macros for each library? Would it only be to be able to selectively use "manual" visibility in some libraries but "automatic" visibility (i.e., export everything) in others?
I'm not sure there is a use case that justifies the additional complexity that would have to be added for that.

I also agree that all functions that are defined in public headers should also be exported.
Which functions these should be is probably a good question for a different task.

If the code can be simplified by applying the visibility attributes to a namespace, that could be an option as well.
But IIUC, all of this visibility handling is compiler specific. Are there compilers that don't support visibility attributes on namespaces?
GCC seems to support this since version 4.2 [1].
What about clang or other compiler we'd like to support?

I'll try and compile MXE Octave with jwe's changes. That might tell us which exports are still missing - at least for the Octave Forge packages we build in MXE Octave.

[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764

Markus Mützel <mmuetzel>
Project Member
Wed 16 Dec 2020 10:38:39 PM UTC, comment #5: 

"Isn't the idea to turn everything off (visibility=hidden) and then only selectively re-enable visibility for the symbols that need it?"

Yes.

File static functions are always hidden.  They don't need a visibility attribute for that.  But they can only be used in one file.

Functions that we want to be private in, say, liboctave but that need to be available to more than one file in the sources will also remain hidden in the shared library and have no public declaration.  These functions can't be declared static because they need to be accessible in multiple files.  They would be declared in internal header file(s) that is (are) not installed for users.  For example, we currently have a few header files that we don't install, but we don't prevent users from accessing the functions from the shared library because we don't set the visibility attribute to hidden.

All other functions that appear in public header files should have the visibility=default attribute applied.

BTW, I think we can do this more simply by tagging the "namespace octave" declaration with a visibility attribute.  Then we don't have to tag every individual function.  And if I understand correctly, it should only apply to the symbols in the tagged namespace declaration.  So some "namespace octave" declarations can be hidden and others not.

Currently, nearly everything in Octave has a declaration in a public header file and all symbols are visible in the shared libraries.  If we want to get serious about the visibility attributes, then we should probably also be deciding which symbols really should have declarations in public header files.

John W. Eaton <jwe>
Project Administrator
Wed 16 Dec 2020 09:47:36 PM UTC, comment #4: 

"Marking only some functions in a public header file as visible seems bad to me.  I would find it weird if I could compile something using Octave header files without warning but not link my program because of symbol visibility.  So it seems to me that we should mark everything in public header files as visible."

I agree, this seems weird to me and I don't think we should do it.

"We should only need visibility=hidden for functions that need to be shared between object files in the same shared library (so they can't be declared static within one file) but that are not considered part of the public interface for the shared library.  Is that correct?"

Isn't the idea to turn everything off (visibility=hidden) and then only selectively re-enable visibility for the symbols that need it?  In my mind that required marking the public interface functions AND the functions shared between files which are not public.  Any file static function would then be hidden by default and that would be okay.

Rik <rik5>
Project Administrator
Wed 16 Dec 2020 06:06:15 PM UTC, comment #3: 

I started looking at visibility.  I'm attaching two changesets.  The first allows me to almost build Octave using separate -DLIBNAME_DLL macros for each shared library that we create.  But in the end it fails with the error:

/usr/bin/ld: libgui/.libs/liboctgui.so: undefined reference to `Array<octave_value>::resize_fill_value() const'

That seems to be happening because the Array<T> class is marked as hidden when we try to instantiate Array<octave_value> when building liboctinterp.  To work around that problem, the original API tags that were added for MSVC were applied to the template instantiations themselves, not the template declarations.  But that doesn't seem to work with GCC, which issues messages like

In file included from /home/jwe/src/octave/liboctave/array/Array-voidp.cc:35:
/home/jwe/src/octave/liboctave/array/Array.cc:2769:22: warning: attribute ignored in explicit instantiation ‘class Array<void*>’ [-Wattributes]
 2769 |   template API class Array<T>
      |                      ^~~~~~~~
/home/jwe/src/octave/liboctave/array/Array-voidp.cc:45:1: note: in expansion of macro ‘INSTANTIATE_ARRAY’
   45 | INSTANTIATE_ARRAY (void *, OCTAVE_API);
      | ^~~~~~~~~~~~~~~~~
/home/jwe/src/octave/liboctave/array/Array.cc:2769:22: note: no attribute can be applied to an explicit instantiation
 2769 |   template API class Array<T>
      |                      ^~~~~~~~
/home/jwe/src/octave/liboctave/array/Array-voidp.cc:45:1: note: in expansion of macro ‘INSTANTIATE_ARRAY’
   45 | INSTANTIATE_ARRAY (void *, OCTAVE_API);
      | ^~~~~~~~~~~~~~~~~

and doesn't change the instantiation to be visible.

So next I tried to just have one API macro (OCTAVE_API) instead of one for each library.  The second changeset attached here does that (apply it in addition to the first one).

This experiment raises a few questions for me:

Do we really need separate API macros for each library or can we just use one?

In some public header files, we mark entire classes as visible but in others we only mark a few functions as visible.

Marking only some functions in a public header file as visible seems bad to me.  I would find it weird if I could compile something using Octave header files without warning but not link my program because of symbol visibility.  So it seems to me that we should mark everything in public header files as visible.

We should only need visibility=hidden for functions that need to be shared between object files in the same shared library (so they can't be declared static within one file) but that are not considered part of the public interface for the shared library.  Is that correct?

If we want to hide more of the Octave internals, then we need to create more private header files in addition to applying visibility attributes.  The hard part is deciding what interfaces should be public.

(file #50492, file #50493)

John W. Eaton <jwe>
Project Administrator
Mon 04 Apr 2016 11:41:25 AM UTC, comment #2: 

The problem with index_exception::message (as described - but interpreted wrongly - in bug #47587) still puzzles me.

Making it pure virtual and adding definitions to every class that inherits from it (as done in file #36813) does not seem the right way to go.

When I revert that part of the patch and re-compile, I get the following additional linker errors:

libinterp/.libs/liboctinterp.so: undefined reference to `index_exception::message[abi:cxx11]() const'
libinterp/.libs/liboctinterp.so: undefined reference to `typeinfo for index_exception'
libinterp/.libs/liboctinterp.so: undefined reference to `vtable for index_exception'

The last two led to my assumption that index_exception::message was not defined. But it is in lo-array-errwarn.cc.

The first error indicates problems with linking objects that have been compiled with different ABIs. But I do not know where (and if really) this is a problem.

Those three link errors disappear if the definition for index_exception::message is inlined (see attached patch).
(However, I do not know what inlining a virtual function means for the compiler and whether this could lead to changed behavior where "message" is actually overloaded by a child class. AFAICS "message" is not overloaded anywhere in core Octave.)

A similar behavior shows for the destructor of octave_chunk_buffer. To avoid linker errors, the destructor has to be inlined (also included in the new patch).

Maybe someone more experienced can comment on this...

I should already have mentioned in comment #1 that these are "minimal patches": I do not see any more link errors than the ones already mentioned. But most probably there are more functions that should be exposed to get all packages (and any .oct file) to compile...

After updating to the newest Mercurial repo, I see a lot of new warnings (probably from changeset f3f8e1d3e399: avoid mulitple definitions of static function-scope vars (bug #47372)). So I wonder whether that change is working as expected... I'll attach the complete output from make, too.

I cannot test any further since Octave still does not compile because of the functions that are not exported by gnulib when it is compiled with CFLAGS="-fvisibility=hidden" CXXFLAGS="-fvisibility=hidden".

(file #36831, file #36832)

Markus Mützel <mmuetzel>
Project Member
Thu 31 Mar 2016 07:16:13 PM UTC, comment #1: 

I hope it is to OK if I jump in with some results from trial and error.

I applied the patch from comment #0 and build on a freshly cloned default branch after bootstrap, configure with:
make CFLAGS="-fvisibility=hidden" CXXFLAGS="-fvisibility=hidden"
I decorated the functions which threw errors with OCTAVE_API. In this way, the linker errors are down to the following:

src/src_octave_cli-main-cli.o:(.data+0x38): undefined reference to `tzalloc'
src/src_octave_cli-main-cli.o:(.data+0x40): undefined reference to `tzfree'
src/src_octave_cli-main-cli.o:(.data+0x48): undefined reference to `localtime_rz'
src/src_octave_cli-main-cli.o:(.data+0x50): undefined reference to `mktime_z'
src/src_octave_cli-main-cli.o:(.data+0xc0): undefined reference to `fpurge'
src/src_octave_cli-main-cli.o:(.rodata+0x8): undefined reference to `rpl_mbrtowc'
src/src_octave_cli-main-cli.o:(.rodata+0x10): undefined reference to `rpl_nanosleep'
src/src_octave_cli-main-cli.o:(.rodata+0x18): undefined reference to `rpl_mktime'
src/src_octave_cli-main-cli.o:(.rodata+0x20): undefined reference to `rpl_canonicalize_file_name'
src/src_octave_cli-main-cli.o:(.rodata+0x28): undefined reference to `rpl_realpath'
src/src_octave_cli-main-cli.o:(.rodata+0x30): undefined reference to `rpl_fclose'
src/src_octave_cli-main-cli.o:(.rodata+0x38): undefined reference to `rpl_fflush'
src/src_octave_cli-main-cli.o:(.rodata+0x40): undefined reference to `rpl_fseek'
src/src_octave_cli-main-cli.o:(.rodata+0x48): undefined reference to `rpl_fseeko'
libinterp/.libs/liboctinterp.so: undefined reference to `sha512_buffer'
libinterp/.libs/liboctinterp.so: undefined reference to `sha224_buffer'
libinterp/.libs/liboctinterp.so: undefined reference to `md4_buffer'
libinterp/.libs/liboctinterp.so: undefined reference to `sha1_buffer'
libinterp/.libs/liboctinterp.so: undefined reference to `sha256_buffer'
libinterp/.libs/liboctinterp.so: undefined reference to `num_processors'
libinterp/.libs/liboctinterp.so: undefined reference to `rpl_fcntl'
libinterp/.libs/liboctinterp.so: undefined reference to `md2_buffer'
libinterp/.libs/liboctinterp.so: undefined reference to `sha384_buffer'
libinterp/.libs/liboctinterp.so: undefined reference to `md5_buffer'

These are functions (not) exported from gnulib. I do not know how to configure to use the visibility flags for compilation but not for the gnulib part.

With the attached patch applied, a lot of warnings along these lines occur while compiling:

  CXX      libinterp/template-inst/libinterp_liboctinterp_la-Array-tc.lo
In file included from ../libinterp/template-inst/Array-tc.cc:30:0:
../liboctave/array/Array.cc:2748:22: warning: type attributes ignored after type is already defined [-Wattributes]
   template class API Array<T>
                      ^
../libinterp/template-inst/Array-tc.cc:38:1: note: in expansion of macro 'INSTANTIATE_ARRAY'
 INSTANTIATE_ARRAY (octave_value, OCTINTERP_API);
 ^

Hope this helps.

(file #36813)

Markus Mützel <mmuetzel>
Project Member
Fri 26 Feb 2016 05:32:15 PM UTC, original submission:  

By using visibility attributes a programmer can control which functions are exported into the symbol table of a shared object.  By reducing the number of symbols the linker can run faster and the generated shared object is smaller.

For an explanation of the benefits and the approach see: https://gcc.gnu.org/wiki/Visibility.

Octave already has support mostly in place for this.

Steps:

1) make maintainer-clean
2) Apply visibility.patch from this issue report
3) change CFLAGS and CXXFLAGS to include "-fvisibility=hidden"
4) bootstrap
5) configure
6) make

The build currently fails because liboctinterp is looking for symbols that have not been exported from liboctave.  This requires finding the necessary functions and decorating them with OCTAVE_API so they are exported into the symbol table of liboctave.  This is where things stand today (2/26/2016).

Rik <rik5>
Project Administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #50492:  visibility-patch-1.txt added by jwe (127KiB - text/plain)
file #50493:  visibility-patch-2.txt added by jwe (155KiB - text/plain)
file #36831:  visibility3.patch added by mmuetzel (28KiB - text/x-diff)
file #36832:  output_make.log added by mmuetzel (164KiB - application/octet-stream)
file #36813:  visibility2.patch added by mmuetzel (25KiB - text/x-diff)
file #36475:  visibility.patch added by rik5 (1KiB - text/x-diff)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by lachlan (Updated the item)
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by rik5 (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 logged-in users can vote.

     

     

     

     

    Follow 19 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-01-22 mmuetzel StatusReady For Test => Done
        Open/ClosedOpen => Closed
    2021-01-07 mmuetzel Attached File- => Added patch8919_visibility_forward_declare.patch, #50673
    2020-12-31 mmuetzel Attached File- => Added patch8919_clang_fixes.patch, #50591
    2020-12-31 mmuetzel StatusNone => Ready For Test
    2020-12-26 mmuetzel Attached File- => Added patch8919_part4_visibility_Windows.patch, #50572
        Attached File- => Added patch8919_part5_visibility_Windows_fixes.patch, #50573
    2020-12-26 mmuetzel Attached File- => Added patch8919_part1_libgui_graphics_map.patch, #50569
        Attached File- => Added patch8919_part2_mark_API.patch, #50570
        Attached File- => Added patch8919_part3_visibility_Linux.patch, #50571
    2020-12-22 mmuetzel Attached File- => Added patch8919_visibility_part3.patch, #50543
    2020-12-16 jwe Attached File- => Added visibility-patch-1.txt, #50492
        Attached File- => Added visibility-patch-2.txt, #50493
    2020-10-28 mmuetzel Dependencies- => bugs #59373 is dependent
    2016-07-07 lachlan CategoryNone => Core : other
    2016-04-04 mmuetzel Attached File- => Added visibility3.patch, #36831
        Attached File- => Added output_make.log, #36832
    2016-03-31 mmuetzel Attached File- => Added visibility2.patch, #36813
    2016-02-26 rik5 Attached File- => Added visibility.patch, #36475

    Back to the top


    Powered by Savane 3.9