similar to: [cfe-dev] [RFC] __attribute__((internal_linkage))

Displaying 20 results from an estimated 500 matches similar to: "[cfe-dev] [RFC] __attribute__((internal_linkage))"

2015 Nov 02
2
[cfe-dev] [RFC] __attribute__((internal_linkage))
> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris > Lattner via llvm-dev > Sent: Saturday, October 31, 2015 2:58 PM > To: sstewartgallus00 at mylangara.bc.ca > Cc: LLVM Developers > Subject: Re: [llvm-dev] [cfe-dev] [RFC] __attribute__((internal_linkage)) > > Hi Stewart, > > I saw this get brought up at
2015 Nov 09
3
[cfe-dev] [RFC] __attribute__((internal_linkage))
With respect only to '__attribute__((internal_linkage))', not 'nodebug' and other parts of this topic; does hiding "some" members and not others not introduce a violation of the ODR because some members of the class as it appears in one translation unit are not the same actual definitions as the apparently "same" members of the class in another translation unit?
2016 Jul 13
3
[cfe-dev] [RFC] __attribute__((internal_linkage))
Hi Evgenii, I was wondering what the status is of your work to attach "internal_linkage" to methods of standard library classes in libc++. The following piece of code doesn't link because a symbol (string::empty) is undefined and it sounds like your work might fix the linkage error I'm seeing. $ cat test1.cpp #include <string> #include <functional> int main() {
2016 Jul 13
3
[cfe-dev] [RFC] __attribute__((internal_linkage))
Hi Evgenii, I have one question about this (planned) change: what if a function is not inlined? The linker will not ODR merge them with this change, which isn’t great. What makes “internal” linkage more desirable than "linkonce_odr + visibility hidden"? — Mehdi > On Jul 12, 2016, at 6:16 PM, Evgenii Stepanov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi,
2014 Nov 04
6
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
I am an actual end user of LLVM who builds it from source and not a developer of it so I think I have an important perspective that is not represented here. Also I am pretty sure the llvmdev mailing is heavily biased and might not reach actual end users of LLVM. I use the Autotools build system for a number of reasons. If compromises or reasonable workarounds could be found I would be okay with
2008 Jun 07
2
When to send "post" and "get" in blocks.
Hi, I''m new to RSpec. I have a question about how to write controller specs. Here''s a code generated by scaffolding (with Rspec). def do_get get :index end it "should be successful" do do_get response.should be_success end it "should render index template" do do_get response.should
2014 Nov 05
4
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
Hello, thank you for the thoughts. > Have you seen the docs for CMake3.0 [1] (see cmake-buildsystem > especially)? They certainly aren't perfect but they are considerably > better than what was there before. Okay, the documentation has come a long way since 3.0 although it still needs a bit of polish. > I wouldn't say that much "important functionality is plain
2009 Jan 10
2
Problem with compiling shared C/C++ library for loading into R (Linux)
I am using the .Call interface to call c++ code from R. For that, I am trying to create a dynamic library (mylib.so) using "R CMD SHLIB" by linking my own c++ code and an external c++ library (blitz++). The makefile works fine on my Mac, produces mylib.so and I am able to call .Call() from R, but on a linux server (I think Debian), I got the following error: ---------- /usr/bin/ld:
2009 Jan 10
2
Problem with compiling shared C/C++ library for loading into R (Linux)
I am using the .Call interface to call c++ code from R. For that, I am trying to create a dynamic library (mylib.so) using "R CMD SHLIB" by linking my own c++ code and an external c++ library (blitz++). The makefile works fine on my Mac, produces mylib.so and I am able to call .Call() from R, but on a linux server (I think Debian), I got the following error: ---------- /usr/bin/ld:
2001 Dec 05
3
trouble with R CMD INSTALL for building my own library
Hi, I have built a library that consists of a piece of C code and some R functions. To build it into a library that I can load using library() command, I have followed "Writing R Extensions" and made sub-directories such as mylib/R and mylib/src. But when I run R CMD INSTALL mylib, nothing seems to be happening with src directory, i.e., no C compiling. I have probably missed some key
2001 Dec 05
3
trouble with R CMD INSTALL for building my own library
Hi, I have built a library that consists of a piece of C code and some R functions. To build it into a library that I can load using library() command, I have followed "Writing R Extensions" and made sub-directories such as mylib/R and mylib/src. But when I run R CMD INSTALL mylib, nothing seems to be happening with src directory, i.e., no C compiling. I have probably missed some key
2012 Jun 01
1
Error: package 'myLib' is not installed for 'arch=i386'
Hello, I 'd like to use some functions in myLib. So I do: library(myLib) Then I get this message: Error: package 'myLib' is not installed for 'arch=i386' > sessionInfo() R version 2.13.2 (2011-09-30) Platform: i386-pc-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=French_France.1252 LC_CTYPE=French_France.1252 LC_MONETARY=French_France.1252 LC_NUMERIC=C
2011 Sep 14
1
Building R package with precompiled shared library
Dear R users, we are trying to build a R package that includes a precompiled shared library, let's say mylib.so. We created the skeleton of the package and we moved the mylib.so file into the libs folder that we created at the same level of the folders man and R. Moreover we created the file NAMESPACE and we added the line useDynLib(mylib, .registration=TRUE). The building step seems to work
2010 Jan 26
1
library.dynam
hi, i'm having some trouble getting a package to load a shared library object in .onLoad(...) i have a shared object file, say "mylib.so". if i start an R session, and via the CLI specify the actual library via: > dyn.load("mylib.so") everything works quite well (i.e. i can then follow with some .Call (...) methods) now, i'd like to include this shared library in
2009 Jun 19
0
[LLVMdev] How to call C++ code from LLVM
On Thu, Jun 18, 2009 at 3:57 PM, Jules Jacobs<julesjacobs at gmail.com> wrote: > How can I call C++ libraries (LLVM & Qt for example) from a language that's > implemented on top of LLVM? You can call them the same way a C++ file compiled with llvm-g++ would call them. Essentially, it's complicated enough that you probably don't want to do it for any interface of
2009 Jun 18
3
[LLVMdev] How to call C++ code from LLVM
Hi, How can I call C++ libraries (LLVM & Qt for example) from a language that's implemented on top of LLVM? Thanks, Jules -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090619/4621508b/attachment.html>
2016 Jun 19
2
llvm-bjdump and ELF-ARM/Thumb
Hi Everyone, When I used llvm-objdump to disassemble an ELF armv7 or thumb I have this error message: llvm-objdump: warning: invalid instruction encoding This message appears directly into the output and the output is mostly wrong (the invalid instruction create a shift in the addresses) : 1a6d: ff 2f e1 08 stmeq r1!, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11, sp} ^ 1a71: 30
2011 May 19
1
r-2.13 fails make check
I am only reporting this because it is the current release branch and not devel. R-2.13 from svn revision 55957 builds fine, but fails make check. This happened with a fresh svn checkout 12 hours ago and it still happens as of now. Two days ago I could build R-2.13 and it passed make check on the same system, so I doubt it is a system problem. But just in case my system details are a fresh
2016 Apr 20
3
Fresh build from source of R-3.2.5 failing "make check" under 64-bit Ubuntu
Hi, Let me justify building R from source. While I can obtain R built for me under Ubuntu, I tend to build it from scratch as we use a NFS-shared build as well as shared R libraries for all the bioinfo staff at this company. Only one build and one set of packages to ensure uniformity across all workstations. My problem is that despite using a pretty standard build process, I am failing at the
2006 Jun 08
1
[LLVMdev] Profiling dynamically loaded libraries
Hi, Standard approach to profiling dynamically loaded libraries with gprof doesn't seem to work with LLVM: export LD_PROFILE=Mylib.so export LD_PROFILE_OUTPUT=. make ENABLE_PROFILING=1 // compiling my project opt -load Profile/Mylib.so -options... but no Mylib.so.profile (or gmon.out) is produced. Profiling libc.so.6 usage by "ls -l", however, works fine. Could anyone explain