On 05/10/2012 06:18 PM, Tor Lillqvist wrote:
This patch makes visibility detection work for me in my 10.4 tree. The
build is still going so I can't say if the result will work;)
Tried a 10.4 build over the weekend, and it worked fine again for me.
Thanks,
Stephan
https://bugs.freedesktop.org/show_bug.cgi?id=37044
This is one of our oldest bugs, looking at the backtraces I'm fairly
sure this has to be triggered by having two differently-layout structs
called TransliterationChgData, one in sw and one in editeng, seeing as
the crash is happening in editeng
On 10/05/12 11:45, Caolán McNamara wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=37044
This is one of our oldest bugs, looking at the backtraces I'm fairly
sure this has to be triggered by having two differently-layout structs
called TransliterationChgData, one in sw and one in
always amazing at how native linkers on the various platforms find new
and different ways to completely screw things up.
Isn't this more a case of it just working by accident on ELF and
Windows platforms?
--tml
___
LibreOffice mailing list
On 10/05/12 12:18, Tor Lillqvist wrote:
always amazing at how native linkers on the various platforms find new
and different ways to completely screw things up.
Isn't this more a case of it just working by accident on ELF and
Windows platforms?
to some extent yes (in that if you have a
that sw can call it? don't we use default hidden visibility on Mac
platform?
Don't think so. At least in that Mac build tree I have that uses Xcode
3 and its gcc 4.0.1 and the 10.4 SDK, config_host.mk ends up with
HAVE_GCC_VISIBILITY_FEATURE blank. On the other hand,
On 10/05/12 12:43, Tor Lillqvist wrote:
that sw can call it? don't we use default hidden visibility on Mac
platform?
Don't think so. At least in that Mac build tree I have that uses Xcode
3 and its gcc 4.0.1 and the 10.4 SDK, config_host.mk ends up with
HAVE_GCC_VISIBILITY_FEATURE blank.
Interestingly enough, the reason why in my 10.4 Mac build tree
(using Xcode 3, and thus gcc 4.0.1 and the 10.4 SDK),
HAVE_VISIBILITY_FEATURE gets unset is that the checking if STL
headers are visibility safe test fails. The earlier checking whether
ccache /Xcode3/usr/bin/gcc-4.0
On 05/10/2012 01:06 PM, Tor Lillqvist wrote:
i'm not all that familiar with how MachO linker works (other than its
fancy install_names :).
You mean the weird @__
stuff? I think that is something we can get rid of once we stop
supporting 10.4.
On 05/10/2012 01:56 PM, Tor Lillqvist wrote:
Interestingly enough, the reason why in my 10.4 Mac build tree
(using Xcode 3, and thus gcc 4.0.1 and the 10.4 SDK),
HAVE_VISIBILITY_FEATURE gets unset is that the checking if STL
headers are visibility safe test fails. The earlier checking whether
This patch makes visibility detection work for me in my 10.4 tree. The
build is still going so I can't say if the result will work;)
Anyway, a summary of the changes here:
- Don't hardcode the -shared, -fpic and -Wl,-z,defs options or the .so
suffix for shared libraries Use platform-specific
This patch makes visibility detection work for me in my 10.4 tree. The
build is still going so I can't say if the result will work;)
Yes, seems to work, so pushed. Will see if it breaks something for
others, or for instance with Xcode 2 and/or PPC.
--tml
Yes, seems to work, so pushed.
That was a bit premature, I hadn't noticed that in fact the
-fvisible=hidden stuff didn't get passed to the compiler after all
thanks to the order of assignments to the gb_C*FLAGS variables in the
gbuild macosx,mk file. I fixed that, and now then I get linking
13 matches
Mail list logo