similar to: [LLVMdev] make llvm-ld to link 64-bits libs???

On Mon, Aug 01, 2005 at 05:13:15PM -0500, Nicholas Riley wrote: > The attached patch fixes this. ...but had tabs in it. Misha kindly reminded me off-list that this was bad. Try this one instead. -- Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley> -------------- next part -------------- Index: tools/gccld/GenerateCode.cpp

gccld passes -shared through if it's generating a shared library, but if you're compiling a program that needs to have its symbols externally accessible, it doesn't pass -export-dynamic through to gcc for the final link. The attached patch fixes this. I've tested with a small test case I sent Chris, and with Python; both seem to work. I also fixed some inaccurate comments in

gccld would barf if you tried to specify the full pathname of an archive on the command line to gcc, (e.g., instead of gcc ... -L/full/path/to -lFOO you say gcc ... /full/path/to/libFOO.a) which many GNU Makefiles try to do. This patch fixes that. Ok to commit? -- gaeke at uiuc.edu gccld.cpp: Fix typo in header. Add IsArchive static method. Roll LoadLibraryFromDirectory() into

Hi,all I tried to run the generated whole-program bitcode of BIND,but I got some information: 0 lli 0x0000000000feda16 1 lli 0x0000000000fed88f 2 libpthread.so.0 0x0000003df340eee0 3 libc.so.6 0x0000003df28332f5 gsignal + 53 4 libc.so.6 0x0000003df2834b20 abort + 384 5 libc.so.6 0x0000003df282c2fa __assert_fail + 234 6 lli

Hello, As previously mentioned I had a linking problem using llvm-ld (http://lists.cs.uiuc.edu/pipermail/llvmdev/2006-February/005246.html) I was getting a error if I used -L switch when linking using the following command line: llvm-ld -o t1.app t1.bc t1.a -L/opt/llvm-1.6/llvm-gcc/lib -lcrtend I believe I've tracked down the problem; in the "main" of tools/llvm-ld.cpp the

I'm not completely sure but something like the build system will still call the native linker when it meets a LLVM object file which causes an error. I once tried to modify the codes of gold-plugin, but the trouble is still there,I think we should hack collect2 of llvm-gcc to make it invoke llvm-ld automatically when it receive the -emit-llvm option(I once tried this, but I found that even

Hello, Man page for 'install.packages' says that if the 'lib' arg is missing, then it "defaults to '.libPaths()[1]' with a warning". But, given the 'install.packages' source code, it seems that this warning is issued only when 'length(.libPaths()) > 1'. So typically, this warning will appear on Mac OS X but not on a Linux or Windows systems

Hi, Last night I was working on trying to get Fax for Asterisk installed. I followed all the instructions, but noted that the download selector only provider an X86 32 Bit binary. The machine I'm using is: 2.6.26-1-amd64 #1 SMP Fri Mar 13 17:46:45 UTC 2009 x86_64 GNU/Linux Consequently, on load it presents an error: [Sep 12 10:25:35] WARNING[31306]: loader.c:368 load_dynamic_module:

On 07/24/2018 07:50 AM, Martin Maechler wrote: >>>>>> Benjamin Tyner >>>>>> on Sat, 21 Jul 2018 13:42:43 -0400 writes: > > Not sure whether it is the same issue as was raised here: > > https://stat.ethz.ch/pipermail/r-devel/2010-October/058729.html > > > but in any case perhaps the problem could partially be remedied on

On 24.07.2018 23:37, Benjamin Tyner wrote: > > > On 07/24/2018 07:50 AM, Martin Maechler wrote: >>>>>>> Benjamin Tyner >>>>>>> ???? on Sat, 21 Jul 2018 13:42:43 -0400 writes: >> ???? > Not sure whether it is the same issue as was raised here: >> ???? > https://stat.ethz.ch/pipermail/r-devel/2010-October/058729.html >>

PE headers code_sz and image_sz indicate more or less, the size of the file and the size of the in-memory image. They are now given the right value. In the ELF format, only the program headers are reliable to determine the actually needed part of the file and the in-memory size. The .bss section should always be marked as NOLOAD for ld since its content shouldn't be included into the binary

Hi, I wanted to load /usr/lib64/libreadline.so into lli (aka "link against it" in llvm-ld). Impossible with llvm-ld, because it uses sys::Path::FindLibrary() which only checks the system lib paths, so it always picked up /usr/lib/libreadline.so. Even copying it into ./mylib, and specifying -L mylib doesn't work - again because sys::Path::FindLibrary() doesn't know about

PE headers code_sz and image_sz indicate more or less, the size of the file and the size of the in-memory image. They are now given the right value. In the ELF format, only the program headers are reliable to determine the actually needed part of the file and the in-memory size. The .bss section should always be marked as NOLOAD for ld since its content shouldn't be included into the binary

Not sure whether it is the same issue as was raised here: https://stat.ethz.ch/pipermail/r-devel/2010-October/058729.html but in any case perhaps the problem could partially be remedied on line 245 of src/library/base/R/library.R by passing the lib.loc to .getRequiredPackages2() ...here is a patch (untested) Index: src/library/base/R/library.R

>>>>> Benjamin Tyner >>>>> on Fri, 20 Jul 2018 19:42:09 -0400 writes: > Here's a trick/workaround; if lib.loc is the path to your > library, then prior to calling library(), >> environment(.libPaths)$.lib.loc <- lib.loc Well, that is quite a "trick" -- and potentially a pretty dangerous one, not intended when making

>>>>> Benjamin Tyner >>>>> on Sat, 21 Jul 2018 13:42:43 -0400 writes: > Not sure whether it is the same issue as was raised here: > https://stat.ethz.ch/pipermail/r-devel/2010-October/058729.html > but in any case perhaps the problem could partially be remedied on line > 245 of src/library/base/R/library.R by passing the lib.loc to

I have a module having the blockaddress instruction. When I link it into another module and delete the original, blockaddress disappears and is replaced by inttoptr (i32 1 to i8*). Please compile and run the attached program to see the demo of this problem. Right after linking modules, blockaddress still exists: @switch.bbs = internal global [3 x i8*] [i8* blockaddress(@my_func,

Sorry if this is the wrong list, but doing a code checkout via Mercurial produces the following: #hg clone http://xenbits.xensource.com/xen-3.2-testing.hg destination directory: xen-3.2-testing.hg requesting all changes adding changesets abort: could not import module ELFCLASS32! transaction abort! rollback completed Is there a workaround for this right now? -- Joe Auty NetMusician: web

Dear R users, I have just upgraded R from 2.11 to 2.12 on Ubuntu 9.04 (see more informations at the end) from the cran apt-get repository. One of the new things concerning the install.packages() function is stated here : install.packages() and remove.packages() with lib unspecified and multiple libraries in .libPaths() inform the user of the library location used with a message

I started using r2u (see https://eddelbuettel.github.io/r2u) recently and thought I was having a problem in that I was getting out-of-date versions of packages. I made enquiries of Dirk Eddelbuettel about this, and he enlightened me as to what the problem really was. I was seeing old versions of packages that were stored in a library, different from /usr/lib/R/site-library. I have a personal