4 ms·

> LD_LIBRARY_PATH While this works, it's generally a bad idea to depend on LD_LIBRARY_PATH. This type of environment override should generally be left as a too

by pdkl95 10y ago

> LD_LIBRARY_PATH While this works, it's generally a bad idea to depend on LD_LIBRARY_PATH. This type of environment override should generally be left as a tool for sysadmins and other integration/workaround needs. Instead, you can bake the library search path into the executable with ld's "-rpath" option. gcc -o foo -Wall -Wl,-rpath,/lib/search/dir > -shared Building a shared library may also require building position independent object files. (CFLAGS += -fPIC). If the library is being distributed, it is also a good idea to set the soname[1]. This can get complicated very quickly, so it's probably better to let something like libtool[2] handle building and managing the library. (Autotools is a lot easier[2] to use that its reputation suggests. Way too many configure.ac scripts are a cargo cult mess) [1] http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN95 http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries... [2] https://autotools.io/libtool/index.html https://autotools.io/libtool/index.html [3] https://autotools.io/whosafraid.html https://autotools.io/whosafraid.html

Annatar 10y ago
Building a shared library may also require building position independent object files. (CFLAGS += -fPIC). And -DPIC.
Keyframe 10y ago
on MacOS you can do: install_name_tool -change new_path old_link executable and you can check paths with otool -L executable
pjc50 10y ago
You can also bake in a relative rpath with $ORIGIN, although the fact that it requires a dollar sign causes endless makefile quoting nightmares: https://enchildfone.wordpress.com/2010/03/23/a-description-of-rpath-origin-ld_library_path-and-portable-linux-binaries/ https://enchildfone.wordpress.com/2010/03/23/a-description-o... This is pretty much the only sensible way to build an executable that statically relies on having a library shipped alongside it.
tannhaeuser 10y ago
I found libtool extremely painful to work with; it will hide your compiled libs in a hidden subdir, will wrap your compiled executable in a fscking shell script that then calls your real binary, it's unable to isolate a build against libs that may or may not be installed on your build system etc. Yet for all magic it does, libtool still doesn't solve the problem of building for a PREFIX (eg. /usr/local) in a temporary directory, and you need a chroot-jail or something for that. From the libtool manual ([1]): Currently it is not generally possible to install into a temporary staging area that contains needed third-party libraries that are not yet visible at their final location. So to build against a shared lib provided by another package, that other package has to be installed at the final destination already. I seriously considered going back to just static libraries at some point. I believe the build system of git does away with autotools alltogether, consisting of just a simple Makefile. Also, a link to phk's libtool rant seems apt here ([2]). [1]: https://www.gnu.org/software/libtool/manual/html_node/Install-mode.html https://www.gnu.org/software/libtool/manual/html_node/Instal... [2]: http://queue.acm.org/detail.cfm?id=2349257&ref=fullrss http://queue.acm.org/detail.cfm?id=2349257&ref=fullrss Edit: typo; make links work
- appleflaxen 10y ago
  both of those links are 404 (at least for me)
  - tannhaeuser 10y ago
    I'm sorry, first one should work now. Second one works for me, but has already been discussed here back in 2012 eg. https://news.ycombinator.com/item?id=4407188 https://news.ycombinator.com/item?id=4407188 .
adekok 10y ago
I've used libtool for 20+ years, and found it to be opaque, baroque, slow, incomprehensible, and just plain broken. Previous comments: https://news.ycombinator.com/item?id=12253252 https://news.ycombinator.com/item?id=12253252
- tannhaeuser 10y ago
  Wish I could upvote your more. The jlibtool I know (and that you seem to have implemented) however is a drop-in replacement for libtool to merely speed up libtool (rather than tar-and-feather libtool out of existence as it deserves to) isn't it? It seems to be used by apache httpd last I checked. Anyway, cudos to those who do something about it. I tried a couple years ago, but haven't followed through.
  - adekok 10y ago
    I took jlibtool from Apache. I don't think they're using it any more. I fixed a lot of bugs. It's now a 95% drop-in replacement for libtool. The builds are MUCH faster than with libtool.
santaclaus 10y ago
> Autotools is a lot easier[2] to use that its reputation suggests. Way too many configure.ac scripts are a cargo cult mess While also utterly horrible, I find CMake to be marginally less utterly horrible than Autotools, and most new projects seem to use CMake over Autotools.
gumby 10y ago
Using libtool just shifts your learning some (mild) arcana about how libraries work to learning the arcana of libtool. A library is not rocket science, and knowing how they work is important to understand how your compiler works anyway.

by pdkl95 10y ago

Annatar 10y ago

Building a shared library may also require building position independent object files. (CFLAGS += -fPIC). And -DPIC.

Keyframe 10y ago

on MacOS you can do: install_name_tool -change new_path old_link executable and you can check paths with otool -L executable

pjc50 10y ago

You can also bake in a relative rpath with $ORIGIN, although the fact that it requires a dollar sign causes endless makefile quoting nightmares: https://enchildfone.wordpress.com/2010/03/23/a-description-of-rpath-origin-ld_library_path-and-portable-linux-binaries/ https://enchildfone.wordpress.com/2010/03/23/a-description-o... This is pretty much the only sensible way to build an executable that statically relies on having a library shipped alongside it.

tannhaeuser 10y ago

I found libtool extremely painful to work with; it will hide your compiled libs in a hidden subdir, will wrap your compiled executable in a fscking shell script that then calls your real binary, it's unable to isolate a build against libs that may or may not be installed on your build system etc. Yet for all magic it does, libtool still doesn't solve the problem of building for a PREFIX (eg. /usr/local) in a temporary directory, and you need a chroot-jail or something for that. From the libtool manual ([1]): Currently it is not generally possible to install into a temporary staging area that contains needed third-party libraries that are not yet visible at their final location. So to build against a shared lib provided by another package, that other package has to be installed at the final destination already. I seriously considered going back to just static libraries at some point. I believe the build system of git does away with autotools alltogether, consisting of just a simple Makefile. Also, a link to phk's libtool rant seems apt here ([2]). [1]: https://www.gnu.org/software/libtool/manual/html_node/Install-mode.html https://www.gnu.org/software/libtool/manual/html_node/Instal... [2]: http://queue.acm.org/detail.cfm?id=2349257&ref=fullrss http://queue.acm.org/detail.cfm?id=2349257&ref=fullrss Edit: typo; make links work

appleflaxen 10y ago
both of those links are 404 (at least for me)
- tannhaeuser 10y ago
  I'm sorry, first one should work now. Second one works for me, but has already been discussed here back in 2012 eg. https://news.ycombinator.com/item?id=4407188 https://news.ycombinator.com/item?id=4407188 .

adekok 10y ago

I've used libtool for 20+ years, and found it to be opaque, baroque, slow, incomprehensible, and just plain broken. Previous comments: https://news.ycombinator.com/item?id=12253252 https://news.ycombinator.com/item?id=12253252

tannhaeuser 10y ago
Wish I could upvote your more. The jlibtool I know (and that you seem to have implemented) however is a drop-in replacement for libtool to merely speed up libtool (rather than tar-and-feather libtool out of existence as it deserves to) isn't it? It seems to be used by apache httpd last I checked. Anyway, cudos to those who do something about it. I tried a couple years ago, but haven't followed through.
- adekok 10y ago
  I took jlibtool from Apache. I don't think they're using it any more. I fixed a lot of bugs. It's now a 95% drop-in replacement for libtool. The builds are MUCH faster than with libtool.

santaclaus 10y ago

> Autotools is a lot easier[2] to use that its reputation suggests. Way too many configure.ac scripts are a cargo cult mess While also utterly horrible, I find CMake to be marginally less utterly horrible than Autotools, and most new projects seem to use CMake over Autotools.

gumby 10y ago

Using libtool just shifts your learning some (mild) arcana about how libraries work to learning the arcana of libtool. A library is not rocket science, and knowing how they work is important to understand how your compiler works anyway.