similar to: [LLVMdev] [lld] Handling multiple -init/-fini command line options

On Mon, Dec 8, 2014 at 8:39 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 12/8/2014 11:09 AM, Joerg Sonnenberger wrote: >> >> On Mon, Dec 08, 2014 at 10:21:49AM -0600, Shankar Easwaran wrote: >>> >>> The DT_INIT/DT_FINI correspond to one initializer function,where as >>> DT_INIT_ARRAY/DT_FINI_ARRAY is used when there is more than one

On Mon, Dec 8, 2014 at 10:57 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > The dynamic loader handles only one entry for DT_INIT. If there is more than > one init option, we could convert this as an .init_array instead ? > > If that doesnot work, we can come up with a .init_array option but I am not > sure about how will you handle priority with init_array's ?

On Mon, Dec 08, 2014 at 10:21:49AM -0600, Shankar Easwaran wrote: > The DT_INIT/DT_FINI correspond to one initializer function,where as > DT_INIT_ARRAY/DT_FINI_ARRAY is used when there is more than one > initalizer function/finalizer function respectively. This is not true. The difference is that the DT_INIT / DT_FINI function is responsible for calling into the .init / .fini block and

Hi, I have tried another way: ar rcs libsysdeputil.a sysdeputil.o gccld seems to recognize the file type. However, it stills find unresoved symbols which are actually the functions in sysdeputil.o (can be find out with `nm libsysdeputil.a`) The problem disappears if native gcc/ld tool chain is used. As another test, main.c: ----------------- extern void foo(); int main() { foo(); return

On Wed, Mar 27, 2019 at 2:03 AM Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Tue, Mar 26, 2019 at 11:13 AM bd1976 llvm <bd1976llvm at gmail.com> wrote: > >> Thanks Saleem/James. >> >> On Tue, Mar 26, 2019 at 5:15 AM Saleem Abdulrasool <compnerd at compnerd.org> >> wrote: >> >>> Yes, I don't think that supporting all

Dear all, I tried to install rgl package on my linux machine fc5, I got an error. Here I run R as user, $ R > options(repos=c(CRAN="http://cran.at.r-project.org/")) > install.packages("rgl", lib="/home/subianto/local/lib/R/library/site-packages", dependencies=TRUE) trying URL 'http://cran.at.r-project.org/src/contrib/rgl_0.67-2.tar.gz' Content type

Hi, I have conventional directory structure for a pass taken from project examples. I want to build a tool which makes usage of a shared library which is included in the project. This means that I have library here: # lib/foo/*.cc and after compilation the library is placed here # Debug/lib/libfoo.so My tool is located here: # tool/test_foo # cat tool/Makefile LEVEL = ../ TOOLNAME=test_foo

On Fri, 2 Jun 2006, Nai Xia wrote: > And the command lines: > > llvm-gcc -c -o main.o main.c > gcc -o foo.o foo.c > ar rcs libfoo.a foo.o > llvm-gcc -Wl,-native main.o -L. -lfoo > > It's *OK* > > Thanks in advance for solving my problem. :) > And I personally think it may possiblely puzzle other users, > maybe it deserves its place in FAQ or in man page for

> Yes, this is no problem. You can do something like > this: > > $ llvmgcc X.c -c -o X.bc > $ llc X.bc -o X.s > $ gcc Y.c -o Y.o -c > $ gcc X.s Y.o -o program > $ ./program Ok, fine, and what about the interpreter? It takes 100% llvm, doesn't it? Or is there some kind of import facility (perhaps as an specially interpreted call or as an extension to llvm which makes

Thanks Saleem/James. On Tue, Mar 26, 2019 at 5:15 AM Saleem Abdulrasool <compnerd at compnerd.org> wrote: > Yes, I don't think that supporting all options is entirely possible. But, > there is certainly some allure to it, as it is a really powerful feature > (which you can tell from the behaviour of link and `.drectve` section). > The problem with all options is that

On Sun, Mar 24, 2019 at 9:51 PM Saleem Abdulrasool <compnerd at compnerd.org> wrote: > Sorry for the late chiming in. > > Yes, swift does use autolinking, and I would like to use that on all the > targets. The only target which does not support this functionality > currently are ELF based. That said, I think that `#pragma comment(link, > ...)` is insufficient for my

On Fri, 2 Jun 2006, Nai Xia wrote: > The Makefile is sth like this: > > vsftpd: $(OBJS) > gccld -r -native -o vsftpd.o $(OBJS) -L/home/xianai/my_projects/llvm/cfrontend/x86/llvm-gcc/lib/ -lcrtend > gcc -o vsftpd vsftpd.o sysdeputil.o `./vsf_findlibs.sh` > > > But the gcc/ld still cannot find the reference to __main. > Do I have to compile crtend to native to

I have two patches enclosed below. One for 'ogg' and the other for 'vorbis'. Basically, I was trying to do a 'make dist' and then 'rpm -ta <filename>' to try and generate some nice RPMs for vorbis stuff. Basically in the ogg .spec file, I move the 'libogg.a' and 'libogg.so' stuff into the devel package (all other packages I've seen do

Hi, I am using LLVM to compile vsftp to native x86 ELF code. One of it's object file (sysdeputil) contains inline asm so cannot be compiled by gcc-3.4 frontend. So I decided to firstly link together the llvm objects and libcrtend and compile it to native .o file and then link it with sysdeputil.o . The Makefile is sth like this: vsftpd: $(OBJS) gccld -r -native -o vsftpd.o $(OBJS)

I filed https://bugs.llvm.org/show_bug.cgi?id=42273 last night, about an inconsistency between LTO and non-LTO workflows. The basic scenario is that we have an object file which calls a function "foo", a static library that provides an implementation of "foo", and a shared library that also provides an implementation of "foo". Currently, whether lld chooses the

Are you planning to add support for "-F" and "-framework" to ELF linkers? On Mon, Mar 25, 2019 at 12:51 AM Saleem Abdulrasool via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Sorry for the late chiming in. > > Yes, swift does use autolinking, and I would like to use that on all the > targets. The only target which does not support this functionality >

On Mon, Mar 18, 2019 at 8:02 PM Rui Ueyama <ruiu at google.com> wrote: > On Thu, Mar 14, 2019 at 1:05 PM bd1976 llvm via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Thu, Mar 14, 2019 at 6:27 PM Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> >>> >>> On Thu, Mar 14, 2019 at 6:08 AM bd1976 llvm via

Hi, I noticed that klibc started crashing on 64-bit MIPS and in my quest to fix the bug I got a bit carried away and fixed a few other things as well. Here are various miscellaneous MIPS patches, although the first patch is the important one. Thanks, James *** BLURB HERE *** James Cowgill (5): mips64: compile with -mno-abicalls mips: use -Ttext-segment when linking shared library

On Fri, 2024-02-02 at 17:14 +0000, Timur Tabi wrote: > On Fri, 2024-02-02 at 01:05 +0100, Danilo Krummrich wrote: > > nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call > > their corresponding *_fini() counterpart. This can lead to > > nouveau_sched_fini() being called without struct nouveau_sched ever > > being initialized in the first place. >

On Thu, Mar 21, 2019 at 12:06 AM Rui Ueyama <ruiu at google.com> wrote: > Perhaps there's no one clean way to solve this issue, because previously > all libraries and object files are explicitly given to the linker via a > command line and the order of files in the command line matters. That > assumes human intervention to work correctly. Now, the autolinking feature >