search for: fvisibl

On Tue, Feb 17, 2015 at 10:40 AM, Marc Dietrich <marvin24 at gmx.de> wrote: > This adds clang/gcc visibility macro detection to configure and util/macros.h. > This is can be used to conveniently add e.g. a "HIDDEN" attribute to a function. > > Signed-off-by: Marc Dietrich <marvin24 at gmx.de> > --- > v2: use VISIBILITY_*FLAGS instead of *FLAGS directly >

[Was initially posted on cfe-users, sorry.] Hi, I'm sorry my message is quite long, the TL;DR version is "g++ and clang++ seem to have different opinions on how RTTI, templates, and ELF visibility should interact". I can't tell whether this is a bug or not: I have found no relevant documentation that could help me decide whether this behavior is meant, or not. All I can say

Hi, I am using latest sources on GCC (gcc4.5_branch), LLVM and dragonegg. I am able to build all three bits though unsuccessfull in building. Already done obvious things - checked out the sources as per defined in "Getting the development version" on dragonegg.llvm.org - Modified the llvm-backend.cpp in dragonegg to make available the global plugin_is_GPL_compatible publically -

After trying the recommended use of -O4 -fvisibility=hidden to compile xplor-nih with full LTO optimizations, I discovered three symbols become undefined... llvm-gcc-4 -O4 -fvisibility=hidden -o xplor xplor.o \ \ -L. -lxplorCmd -lxplor -L/Users/howarth/xplor-nih-2.21/bin.Darwin_9_x86/ -lfft -lintVar -lvmd -lpy -lswigpy-xplor -ltclXplor -lswigtcl8-xplor -lnmrPot -lcommon -lmarvin \

Le 25 janv. 09 à 06:01, Jack Howarth a écrit : > After trying the recommended use of -O4 -fvisibility=hidden to > compile xplor-nih with full LTO optimizations, I discovered three > symbols become undefined... > > llvm-gcc-4 -O4 -fvisibility=hidden -o xplor xplor.o \ > \ > -L. -lxplorCmd -lxplor -L/Users/howarth/xplor-nih-2.21/ > bin.Darwin_9_x86/ -lfft -lintVar

I was able to also build sparky (http://www.cgl.ucsf.edu/home/sparky/) at -O4 under llvm-gcc-4.2 and llvm-g++-4.2 on darwin with minor patches... --- sparky/c++/_tkinter.c.orig 2009-01-30 22:14:28.000000000 -0500 +++ sparky/c++/_tkinter.c 2009-01-30 22:16:40.000000000 -0500 @@ -3089,6 +3089,9 @@ } } +PyMODINIT_FUNC +init_tkinter(void)

On Mon, Jan 26, 2009 at 09:57:28AM -0800, Devang Patel wrote: > Hi Jack, > > On Jan 25, 2009, at 10:00 AM, Jack Howarth wrote: > > > Doing that changes the error messages into a bus > > error on the darwin linker. > > > Pl. file bugzilla report (or radar) with a reproducible test case so > that we can investigate this linker crash. > > As you

Hi Rehman, if I understand right the plugin works fine if you compile it with -fvisibility=hidden, and replace LLVM_GLOBAL_VISIBILITY in llvm-backend.cpp with __attribute__ ((visibility("default"))). Since LLVM_GLOBAL_VISIBILITY is a macro that expands to __attribute__ ((visibility("default"))) if you are not on mingw32 or cygwin, and your gcc version is at least 4, that

Hi, Ben Skeggs latest changes in Mesa cause a build failure (libdrm is latest git ...). Thanks. Johannes gmake[3]: Entering directory `/usr/src/packages/BUILD/Mesa/src/mesa/drivers' gmake[4]: Entering directory `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri' sed -e 's, at INSTALL_DIR@,/usr,' -e 's, at INSTALL_LIB_DIR@,/usr/lib,' -e 's, at

On Sun, Jan 25, 2009 at 11:38:48AM +0100, Jean-Daniel Dupas wrote: > > Le 25 janv. 09 à 06:01, Jack Howarth a écrit : > > > After trying the recommended use of -O4 -fvisibility=hidden to > > compile xplor-nih with full LTO optimizations, I discovered three > > symbols become undefined... > > > > llvm-gcc-4 -O4 -fvisibility=hidden -o xplor xplor.o \ >

Patch 1 adds a check for the compilers visibility macro to configure.ac. Patch 2 avoids redefined symbol errors in clang of the tls entry points. Based on a suggestion from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> in http://llvm.org/bugs/show_bug.cgi?id=19778. Tested with gcc 4.9 and clang 3.6(rc) Marc Dietrich (2): configure: add visibility macro detection to configure

>From http://bugs.r-project.org/cgi-bin/R: If you are not sure whether you have observed a bug or not, it is a good idea to ask on the mailing list R-Help by sending an e-mail to r-help at stat.math.ethz.ch rather than submitting a bug report. I'm wondering whether to submit a bug report on this: ============================================================== >

Hi Marc On 17/02/15 09:40, Marc Dietrich wrote: > This adds clang/gcc visibility macro detection to configure and util/macros.h. > This is can be used to conveniently add e.g. a "HIDDEN" attribute to a function. > I believe this should be OK to go in regardless of the status of patch 2. There are just a couple of trivial nitpicks. > Signed-off-by: Marc Dietrich

This probably just works around a layering violation. Can you provide the cmake line that produces a broken build? Cheers, Rafael On Jun 18, 2016 7:34 AM, "Nicolai Hähnle" <llvm-dev at lists.llvm.org> wrote: Hi, since recently I'm getting linker failures in debug builds. The root cause is that -fvisibility-inlines-hidden causes inline functions in explicit template

On Wed, Jul 30, 2014 at 9:48 AM, Thierry Reding <thierry.reding at gmail.com> wrote: > From: Thierry Reding <treding at nvidia.com> > > Checks whether or not the compiler supports the -fvisibility option. If > so it sets the VISIBILITY_CFLAGS variable which can be added to the per > directory AM_CFLAGS where appropriate. > > By default all symbols will be hidden

Apologies for the cross-post, this effects both clang and llvm. I was looking into the startup time of clang on small files ( http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080818/007171.html ) and discovered that a significant amount of our startup time was being spent in the linker resolving weak symbols. At least on Darwin, this was actually the dominant factor in our startup

On 30/07/14 11:16, Christian K?nig wrote: > [CCing Emil as well] > > Am 30.07.2014 um 11:38 schrieb Maarten Lankhorst: >> Using -export-symbols-regex all private symbols are hidden, resulting in the >> following changes: > > Wasn't "-export-symbols-regex" exactly that stuff we are trying to avoid in mesa? > IMHO we should try to pick up Thierry

On Fri, Jun 13, 2014 at 08:34:03PM +0200, Akim Demaille wrote: > > Le 5 juin 2014 à 00:32, Rafael Espíndola <rafael.espindola at gmail.com> a écrit : > > > I think the difference is actually in the c++ library. It looks like > > libstdc++ changed to always use strcmp of the typeinfo names: > > > >

On Sat, Jun 14, 2014 at 6:15 AM Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Fri, Jun 13, 2014 at 08:34:03PM +0200, Akim Demaille wrote: > > > > Le 5 juin 2014 à 00:32, Rafael Espíndola <rafael.espindola at gmail.com> a > écrit : > > > > > I think the difference is actually in the c++ library. It looks like > > > libstdc++

Le 5 juin 2014 à 00:32, Rafael Espíndola <rafael.espindola at gmail.com> a écrit : > I think the difference is actually in the c++ library. It looks like > libstdc++ changed to always use strcmp of the typeinfo names: > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=149964 > > Should we do the same with libc++? What do people think about this issue?