similar to: [LLVMdev] Revised patch to make gccld link native .so's

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 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

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 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

Hello, I have a patch that: 1. Allows gccld to link shared libraries natively.. 2. Passes along -rpath and -soname to the native linker... 3. Fixes a bug where the bytecode files were kept around after native linking... 4. Removes a now unnecessary warning for native linking... The result is that we are >' '< close to having Qt4 both compile *and* link with the LLVM toolchain.

On Sun, 20 Feb 2005 19:42:34 -0500, Adam Treat wrote: > The result is that we are >' '< close to having Qt4 both compile *and* link > with the LLVM toolchain. Wow, cool! Mind if I ask what is motivating this work? thanks -mike

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 >

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 >

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 llvm team! I'm currently working on the extended version of llvm-ld, which has an ability to check if all the symbols present (and fail if some symbols are not resolved), treat archives in the right way (link all the object files in the archive if it's specified as the regular input, not as -l) and the most important to my project feature: to link against bitcode "shared

Greetings, I just upgraded my samba server to the latest Debian stable package, which is listed as: 2.2.3a-6. I got the following errors in the logs when a user installs a printer: barfoo smbd[1083]: [2002/08/30 10:36:12, 0] libsmb/cliconnect.c: attempt_netbios_session_request(977) barfoo smbd[1083]: attempt_netbios_session_request: FOOBAR rejected the session for name *SMBSERVER

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 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 llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> At Sony we offer autolinking as a feature in our ELF toolchain. We would >> like to see full support for this feature upstream as there is anecdotal >> evidence that

"Not that it really matters, but" Can someone explain how the row numbers get assigned in the following sequence? It looks like something funky happens when rbind() coerces 'bar' into a dataframe. In either sequence of rbind below, once you get past the first two rows, the row numbers count normally. Rgames> (foo<-data.frame(x=5,y=4,r=3)) x y r 1 5 4 3 Rgames>

Hello R-world! This is my first post to the R list, so I feel that I need to say thanks to the community (I'm using R now for 5 months)! I'd greatly appreciate if somebody could explain some odd behavior of ".Fortran" to me. Let's assume a primitive Fortran subroutine barfoo.f ---------------------------- subroutine bar(y, v) double precision y real v

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

On Tue, 2015-09-08 at 10:24 +0100, Ian Campbell wrote: > Stubdomains When I passed these notes around internally for sanity checking we ended up discussing this issue, since we decided it would be better to move this to xen-devel I'm quoting the thread below with permission. It was a bit tricky to flatten the thread into a single mail, but it wasn't too "branchy" so I think

Hi, The LLD linker in gnu flavor mode accepts multiple -init/-fini command line options. For _all_ symbols specified by these options the linker creates appropriate entries in the .init_array/.fini_array sections. But it looks like LD and Gold linkers do not support this feature and take in account only the last -init/-fini options. % cat foo.c int a = 0; void foo() { a += 1; } void bar() { a +=

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 Tue, 2015-09-08 at 18:38 +0000, Antti Kantee wrote: > On 08/09/15 16:15, Ian Campbell wrote: > > On Tue, 2015-09-08 at 15:03 +0000, Antti Kantee wrote: > > > > > For unikernels, the rump kernel project provides Rumprun, which can > > > provide you with a near-full POSIX'y interface. > > > > I'm not 100% clear: Does rumprun _build_ or _run_