{"action":"created","issue":{"url":"https://api.github.com/repos/numba/llvmlite/issues/202","repository_url":"https://api.github.com/repos/numba/llvmlite","labels_url":"https://api.github.com/repos/numba/llvmlite/issues/202/labels{/name}","comments_url":"https://api.github.com/repos/numba/llvmlite/issues/202/comments","events_url":"https://api.github.com/repos/numba/llvmlite/issues/202/events","html_url":"https://github.com/numba/llvmlite/issues/202","id":174908617,"number":202,"title":"[Freebsd] llvmlite libgcc_s.so.1 issue","user":{"login":"davidkallie","id":13819239,"avatar_url":"https://avatars.githubusercontent.com/u/13819239?v=3","gravatar_id":"","url":"https://api.github.com/users/davidkallie","html_url":"https://github.com/davidkallie","followers_url":"https://api.github.com/users/davidkallie/followers","following_url":"https://api.github.com/users/davidkallie/following{/other_user}","gists_url":"https://api.github.com/users/davidkallie/gists{/gist_id}","starred_url":"https://api.github.com/users/davidkallie/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/davidkallie/subscriptions","organizations_url":"https://api.github.com/users/davidkallie/orgs","repos_url":"https://api.github.com/users/davidkallie/repos","events_url":"https://api.github.com/users/davidkallie/events{/privacy}","received_events_url":"https://api.github.com/users/davidkallie/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2016-09-03T17:51:40Z","updated_at":"2016-09-05T21:50:29Z","closed_at":null,"body":"Hello everyone,\r\n\r\nAfter trying to isolate a libgcc_s.so.1 loading issue for numba, it turns out that llvmlite was the culprit. The original issue can be seen here:\r\nhttps://github.com/numba/numba/issues/2001\r\nhttps://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211347\r\nhttps://forums.freebsd.org/threads/57080/\r\n \r\nIn short the issue seems that -rpath is not being set for libllvmlite.so, the /lib/libgcc_s.so.1 is from legacy gcc 4.2.1, which is used for backwards compatibility. Newer versions of gcc are found in /usr/local/lib/gcc{GCC_VER}/libgcc_s.so.1. Below is the ldd output of libllvmlite.so, pointing to the incorrect libgcc_s.so.1\r\n\r\n>ldd /usr/local/lib/python2.7/site-packages/llvmlite/binding/libllvmlite.so\r\n/usr/local/lib/python2.7/site-packages/llvmlite/binding/libllvmlite.so:\r\n        librt.so.1 => /usr/lib/librt.so.1 (0x281f6000)\r\n        libncurses.so.8 => /lib/libncurses.so.8 (0x281fc000)\r\n        libthr.so.3 => /lib/libthr.so.3 (0x28239000)\r\n        libz.so.6 => /lib/libz.so.6 (0x2825a000)\r\n        libm.so.5 => /lib/libm.so.5 (0x2826e000)\r\n        libc++.so.1 => /usr/lib/libc++.so.1 (0x28295000)\r\n        libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x28343000)\r\n        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2835d000)\r\n        libc.so.7 => /lib/libc.so.7 (0x2806f000)\r\n\r\nIs there a way for rpath to be easily added to the setup.py script?\r\n\r\nThanks\r\n\r\nPS. I am **not** using conda, I am using the FreeBSD ports system. This is because the conda installer hasn't been tested on FreeBSD or ported over. Aside from this rpath issue everything works just fine, loading numpy ahead of time curbs the issue, but this isn't correct to include numpy before hand."},"comment":{"url":"https://api.github.com/repos/numba/llvmlite/issues/comments/244814822","html_url":"https://github.com/numba/llvmlite/issues/202#issuecomment-244814822","issue_url":"https://api.github.com/repos/numba/llvmlite/issues/202","id":244814822,"user":{"login":"davidkallie","id":13819239,"avatar_url":"https://avatars.githubusercontent.com/u/13819239?v=3","gravatar_id":"","url":"https://api.github.com/users/davidkallie","html_url":"https://github.com/davidkallie","followers_url":"https://api.github.com/users/davidkallie/followers","following_url":"https://api.github.com/users/davidkallie/following{/other_user}","gists_url":"https://api.github.com/users/davidkallie/gists{/gist_id}","starred_url":"https://api.github.com/users/davidkallie/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/davidkallie/subscriptions","organizations_url":"https://api.github.com/users/davidkallie/orgs","repos_url":"https://api.github.com/users/davidkallie/repos","events_url":"https://api.github.com/users/davidkallie/events{/privacy}","received_events_url":"https://api.github.com/users/davidkallie/received_events","type":"User","site_admin":false},"created_at":"2016-09-05T21:50:29Z","updated_at":"2016-09-05T21:50:29Z","body":"Well there are different environment variables that get set. Numba, which is python specific only handles them nicely, however in llvmlite, there is some hardcoded Makefiles. Specifically Makefile.freebsd, where the `LDFLAGS` is set using `LDFLAGS=$(LLVM_LDFLAGS)`.\r\n\r\nHowever, when I define some variables for buliding, the Makefile.freebsd does not pick them up -- which is strange. Also `LLVM_LDFLAGS` is hard set in ffi/build.py.\r\n\r\nI will have to do some investigating still as to why that is, my fix isn't one that I like. It would be nice to either piggy back on `LLVM_LDFLAGS`, or something else.\r\n\r\nAs far as I can tell, llvmlite does not seem to respect passing `-Wl,-rpath=\"\"` as numba does. What is odd is that `${LOCALBASE}` is accepted by the Makefile.freebsd, but no other variable. `${LOCALBASE}` is a definition for FreeBSD for `/usr/local`"}}
{"actor":{"display_login":"davidkallie"}}