lmi
[Top][All Lists]
Advanced

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

[lmi] Shared-library "attributes"


From: Greg Chicares
Subject: [lmi] Shared-library "attributes"
Date: Mon, 16 Oct 2006 14:48:49 +0000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

Evgeniy--I'd like to port the change you made yesterday in
'wx_new.hpp', or something like it, to both our main trunks.
Is it possible to make it more similar to 'so_attributes.hpp'?

In 'so_attributes.hpp', I think this
  #if defined LMI_USE_SO_ATTRIBUTES
serves the same purpose as
  #   if !defined HAVE_CONFIG_H // not using autoconf.
but is even more general because any other build system that,
like autoconf, doesn't define LMI_USE_SO_ATTRIBUTES would get
the same behavior as autoconf. And it would be easier to make
elf 'visibility' work if both these headers were similar. (BTW,
I've tested these headers on msw only, not *nix, so I don't know
whether the elf stuff works at all).

However, does autoconf simply not support elf "visibility" or
msw "dll[ex|im]port" attributes? For 'wx_new.hpp', this code:
  #   else // using autoconf. use auto import feature on windows
  #       define LMI_WX_NEW_SO
  #   endif // !defined HAVE_CONFIG_H
would prevent functions like
  LMI_WX_NEW_SO void* operator new  (std::size_t, wx_allocator);
from getting any "decoration" or "attribute", so there wouldn't
be any "visibility" attribute on an elf system either, right?

I guess autoconf relies on '-auto-import', but the maintainer
of the gcc msw port seems to view that as a problematic default:

http://www.nabble.com/Re%3A--Issue-N132340--Question-on-cross-compiling-tf2388863.html#a6667658

[so, if you ever see 0xc0000005 at initialization, then this
might be the cause]

and our own build system disables it:

  # Explicitly disable the infelicitous auto-import default. See:
  #   http://sourceforge.net/mailarchive/message.php?msg_id=15705075

  LDFLAGS = \
    $(gprof_flag) \
    -Wl,-Map,address@hidden \
    -Wl,--disable-auto-import \

Anyway, any potential autotools concern can be deferred, but for
now I'd like to make our two above-cited headers similar.




reply via email to

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