|
« Return to Thread: Bug Report: "make install" on Ubuntu should run "ldconfig" as final step
Re: Bug Report: "make install" on Ubuntu should run "ldconfig" as final step
by Jeremy Tregunna-2
::
Rate this Message:
In my opinion this isn't the responsibility of io, nor any other
library to do. It's not third party developers fault that GNU ld is
"dumb" (I don't use that as derogatory, I use that as you have to tell
it everything to do and when it do it).
Different platforms solve the problem differently, for instance, NeXT
(and now Apple) dyld requires that when you link a library, you tell
the linker where you're going to install it, and that information is
stored in the resulting object file. This is a fragile solution, but
there is "relative path" support, which handles probably 99% of the
cases you'd want to handle, when static paths are of little use.
BSD ld uses a different approach still (though closer related to how
GNU ld does it, but more how GNU ld should do it). It is also
partially dumb, but what happens is, it'll scan its cache first, load
paths into memory, then the runtime linker will check to find any
library in those paths if it's not in its cache already.
Better than 99% of the time, BSD ld finds the appropriate library.
Now, all the systems are a little more complicated than I make it out
to be, but the details are less important than the summary.
On 6-Jun-09, at 11:06 PM, dennisf486 wrote:
> This build problem first occurred a couple years ago for me, and I
> just noticed the latest code I pulled from github still has the same
> issue.
>
> Steps to reproduce the problem:
> - git-clone latest Io code from github
> - make all
> - sudo make install
> - Try to execute "io" (either the newly installed version or the one
> from _build/binaries, doesn't matter)
> - Gives error saying it can't load the IoVM library.
> - Try running "io_static" instead (io_static works)
>
> Temporary workaround:
> - after installing, run "sudo ldconfig"
> - Now run "io", and see that it now works
>
> I spent considerable time tracking this problem down last year. I'm
> still not 100% clear what ldconfig actually *does* but it has
> something to do with linking version-dependent installed library
> file names with version-independent symbolic aliases for the
> libraries. My clue was that when you install a normal .deb package,
> at the end the package says "ldconfig deferred processing now taking
> place". It turns out you can just run ldconfig yourself at any time
> (you have to be root (sudo)). AFAIK it's fairly innocuous and
> running when it isn't needed doesn't cause problems; it just doesn't
> do anything if it isn't needed. Since you have to sudo to make
> install anyway, I would assume just adding "ldconfig" in the end of
> the makefile for make install will work perfectly.
>
> Note that after the first time you run ldconfig after building Io
> from source, you can no longer reproduce the bug because the Linux
> system is already properly set up when you build from source a 2nd
> time.
Regards,
Jeremy Tregunna
jeremy.tregunna@...
library to do. It's not third party developers fault that GNU ld is
"dumb" (I don't use that as derogatory, I use that as you have to tell
it everything to do and when it do it).
Different platforms solve the problem differently, for instance, NeXT
(and now Apple) dyld requires that when you link a library, you tell
the linker where you're going to install it, and that information is
stored in the resulting object file. This is a fragile solution, but
there is "relative path" support, which handles probably 99% of the
cases you'd want to handle, when static paths are of little use.
BSD ld uses a different approach still (though closer related to how
GNU ld does it, but more how GNU ld should do it). It is also
partially dumb, but what happens is, it'll scan its cache first, load
paths into memory, then the runtime linker will check to find any
library in those paths if it's not in its cache already.
Better than 99% of the time, BSD ld finds the appropriate library.
Now, all the systems are a little more complicated than I make it out
to be, but the details are less important than the summary.
On 6-Jun-09, at 11:06 PM, dennisf486 wrote:
> This build problem first occurred a couple years ago for me, and I
> just noticed the latest code I pulled from github still has the same
> issue.
>
> Steps to reproduce the problem:
> - git-clone latest Io code from github
> - make all
> - sudo make install
> - Try to execute "io" (either the newly installed version or the one
> from _build/binaries, doesn't matter)
> - Gives error saying it can't load the IoVM library.
> - Try running "io_static" instead (io_static works)
>
> Temporary workaround:
> - after installing, run "sudo ldconfig"
> - Now run "io", and see that it now works
>
> I spent considerable time tracking this problem down last year. I'm
> still not 100% clear what ldconfig actually *does* but it has
> something to do with linking version-dependent installed library
> file names with version-independent symbolic aliases for the
> libraries. My clue was that when you install a normal .deb package,
> at the end the package says "ldconfig deferred processing now taking
> place". It turns out you can just run ldconfig yourself at any time
> (you have to be root (sudo)). AFAIK it's fairly innocuous and
> running when it isn't needed doesn't cause problems; it just doesn't
> do anything if it isn't needed. Since you have to sudo to make
> install anyway, I would assume just adding "ldconfig" in the end of
> the makefile for make install will work perfectly.
>
> Note that after the first time you run ldconfig after building Io
> from source, you can no longer reproduce the bug because the Linux
> system is already properly set up when you build from source a 2nd
> time.
Regards,
Jeremy Tregunna
jeremy.tregunna@...
« Return to Thread: Bug Report: "make install" on Ubuntu should run "ldconfig" as final step
| Free embeddable forum powered by Nabble | Forum Help |
