octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: duplicate instantiations


From: Jaroslav Hajek
Subject: Re: duplicate instantiations
Date: Tue, 2 Jun 2009 19:44:09 +0200

On Tue, Jun 2, 2009 at 3:19 PM, Jaroslav Hajek <address@hidden> wrote:
> On Tue, Jun 2, 2009 at 2:47 PM, Michael Goffioul
> <address@hidden> wrote:
>> On Tue, Jun 2, 2009 at 1:36 PM, Jaroslav Hajek <address@hidden> wrote:
>>> OK, but I'll wait what people on comp.lang.c++ say. It's not a big
>>> problem since GCC accepts it
>>> (even in -pedantic -ansi, which probably deserves a bug report if I'm
>>> right). I'll alert you if I am about to remove these declarations. I
>>> was already beginning to think Intel C++ is just barking, but I just
>>> tested the online Comeau C++ (on a hopefully equivalent test case),
>>> which is reported to be very good at standard conformance diagnostics,
>>> and it complains as well :(
>>> I'll try to investigate it a bit more. It seems a correct workaround
>>> would be to put a whole specialization (including the decorator) into
>>> Array-*.cc, but that seems really ugly.
>>>
>>> Another option is to simply make the instantiations conditional for
>>> MSVC. This seems to me the most feasible approach for now.
>>
>> Did you ever try to play with the visibility attribute of GCC?
>
> No, I didn't. In fact I didn't know about it, so I need to investigate
> how it works.
> The GCC wiki says that it should reduce the executable size and
> possibly speed up loading, which is something that is certainly worth
> trying. Thanks for the suggestion.
>
>> If the default visibility is "hidden", does GCC make member classes
>> visible if the main class is made visible?
>>
>
>

Hi Michael,

I just tried compiling octave with this patch:

diff --git a/libcruft/misc/oct-dlldefs.h b/libcruft/misc/oct-dlldefs.h
--- a/libcruft/misc/oct-dlldefs.h
+++ b/libcruft/misc/oct-dlldefs.h
@@ -26,6 +26,9 @@
 #if defined (_MSC_VER)
 #define OCTAVE_EXPORT __declspec(dllexport)
 #define OCTAVE_IMPORT __declspec(dllimport)
+#elif __GNUC__ >= 4
+#define OCTAVE_EXPORT __attribute__ ((visibility("default")))
+#define OCTAVE_IMPORT OCTAVE_EXPORT
 #else
 /* All other compilers, at least for now. */
 #define OCTAVE_EXPORT


and get a bunch of undefined references when linking liboctinterp. It
seems that GCC requires the __attribute__ tags be added at the
definition point. That is, we would need to tag Array<T> and other
classes with OCTAVE_API. Would it also work for MSVC? This may be
worth further investigations after 3.2.
I should note that the size of liboctave was reduced by mere 5.8%,
which is really not much.

regards

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


reply via email to

[Prev in Thread] Current Thread [Next in Thread]