Loading ...
Sorry, an error occurred while loading the content.

Re: [linuxham] Re: how to update to hamlib-1.2.9

Expand Messages
  • Rick Kunath
    ... Seems like this comes up every now and then... The quick cram course: Distro provided packages are installed in the /usr tree Locally compiled (by you)
    Message 1 of 9 , Mar 8, 2009
    • 0 Attachment
      On Sunday 08 March 2009 2:28:32 pm d_ziolkowski wrote:
      > I have installed it in home/username.
      >
      > I looked for etc/ld.so.conf. I have ld.so.conf.d
      > in in are 3 files-
      > i486-linux-gnu.conf
      > kde4.conf
      > libc.conf
      >
      > is this the correct folder? I looked at the 3 files and none seem to relate
      > to hamlib or fldigi or grig.

      Seems like this comes up every now and then...

      The quick cram course:

      Distro provided packages are installed in the /usr tree

      Locally compiled (by you) packages are installed in the /usr/local tree

      Generally in a well managed distro, the ld.so.conf file does not include
      the /usr local path. This is by design. All distro provided apps should look
      for and use distro provided packages versions as originally shipped and not
      locally compiled newer or unstable packages. This is for stability. Since the
      existing base of packages has been tested to be stable on a particular
      revision, locally installed later rev packages and libs should not be used
      automatically.

      This is why your distro didn't see your hamlib.

      I never, ever, add the /usr/local tree path to ld.so.conf on any of my
      installations.

      Now, the question, where *did* you install the new hamlib anyway?
      The /usr/local tree as would be the default if you just did a:

      ./configure
      Make
      Su to root
      Make install

      Or somewhere else?

      Some would recommend that you un-install the binary package provided by your
      distro. While this may seem a good idea, your package database won't know
      about your locally compiled and installed Hamlib version, so will still pull
      in the older Hamlib binary package as a dep on binary packages that need it.

      Best solution is to get a binary of the latest Hamlib for your distro and
      install that. This will overwrite (upgrade) your existing Hamlib installation
      and will be visible as a supplied dependency and a shared lib to other apps,
      currently installed or newly built.

      If there is no binary available, create your own rpm/deb and install that. By
      default, as a binary package, this will install into the /usr tree.

      It's easy to setup a local (in your home directory) buildroot to build rpms if
      you need to. Or someone may have already made a binary package available to
      you. I'd look for this if available.

      Alternatively, you can manually specify the /usr/local tree for hamlib on a
      locally built package, but other previously installed binary packages will
      not be able to see the new version if you do that.

      I'll bet there is a binary of the new release available somewhere for your
      distro.

      Rick Kunath, k9ao
    • rich
      ... I am running Ubuntu 8.10, and the ld.so.conf.d folder consist of text files that contain the full added paths. My file name is libhamlib and the text
      Message 2 of 9 , Mar 8, 2009
      • 0 Attachment
        --- In linuxham@yahoogroups.com, "d_ziolkowski" <dan.ziolkowski@...> wrote:

        I am running Ubuntu 8.10, and the ld.so.conf.d folder consist of text files that contain the full added paths. My file name is libhamlib and the text /home/username/hamlib/lib. The contents of the directory is read a boot and when ldconfig is run. It is a root operation so you will need to use "sudo ldconfig" to update the paths. I usually work from a root terminal so I usually forget to sudo. In some distro's the ld.so.conf file is simply a text configuration file that is read instead of a directory. YMMV.

        Rich
        WA4SXZ

        > I have installed it in home/username.
        >
        > I looked for etc/ld.so.conf. I have ld.so.conf.d
        > in in are 3 files-
        > i486-linux-gnu.conf
        > kde4.conf
        > libc.conf
        >
        > is this the correct folder? I looked at the 3 files and none seem to relate to hamlib or fldigi or grig.
        >
        > Thanks Dan
        >
      • Ed
        Why not just open a terminal and cd to the old hamlib and as root (su or sudo) make uninstall Then re-compile the new version. Ed W3NR
        Message 3 of 9 , Mar 8, 2009
        • 0 Attachment
          Why not just open a terminal and cd to the old hamlib and as root (su or
          sudo)

          make uninstall


          Then re-compile the new version.


          Ed W3NR
        • d_ziolkowski
          Now It is not installed, I removed it as it did not work (or---fldigi did not see it). I will try the things indicated below, and see what happens. Thanks all
          Message 4 of 9 , Mar 8, 2009
          • 0 Attachment
            Now It is not installed, I removed it as it did not work (or---fldigi did not see it). I will try the things indicated below, and see what happens.

            Thanks all for the help.

            --- In linuxham@yahoogroups.com, Rick Kunath <k9ao@...> wrote:
            >
            > On Sunday 08 March 2009 2:28:32 pm d_ziolkowski wrote:
            > > I have installed it in home/username.
            > >
            > > I looked for etc/ld.so.conf. I have ld.so.conf.d
            > > in in are 3 files-
            > > i486-linux-gnu.conf
            > > kde4.conf
            > > libc.conf
            > >
            > > is this the correct folder? I looked at the 3 files and none seem to relate
            > > to hamlib or fldigi or grig.
            >
            > Seems like this comes up every now and then...
            >
            > The quick cram course:
            >
            > Distro provided packages are installed in the /usr tree
            >
            > Locally compiled (by you) packages are installed in the /usr/local tree
            >
            > Generally in a well managed distro, the ld.so.conf file does not include
            > the /usr local path. This is by design. All distro provided apps should look
            > for and use distro provided packages versions as originally shipped and not
            > locally compiled newer or unstable packages. This is for stability. Since the
            > existing base of packages has been tested to be stable on a particular
            > revision, locally installed later rev packages and libs should not be used
            > automatically.
            >
            > This is why your distro didn't see your hamlib.
            >
            > I never, ever, add the /usr/local tree path to ld.so.conf on any of my
            > installations.
            >
            > Now, the question, where *did* you install the new hamlib anyway?
            > The /usr/local tree as would be the default if you just did a:
            >
            > ./configure
            > Make
            > Su to root
            > Make install
            >
            > Or somewhere else?
            >
            > Some would recommend that you un-install the binary package provided by your
            > distro. While this may seem a good idea, your package database won't know
            > about your locally compiled and installed Hamlib version, so will still pull
            > in the older Hamlib binary package as a dep on binary packages that need it.
            >
            > Best solution is to get a binary of the latest Hamlib for your distro and
            > install that. This will overwrite (upgrade) your existing Hamlib installation
            > and will be visible as a supplied dependency and a shared lib to other apps,
            > currently installed or newly built.
            >
            > If there is no binary available, create your own rpm/deb and install that. By
            > default, as a binary package, this will install into the /usr tree.
            >
            > It's easy to setup a local (in your home directory) buildroot to build rpms if
            > you need to. Or someone may have already made a binary package available to
            > you. I'd look for this if available.
            >
            > Alternatively, you can manually specify the /usr/local tree for hamlib on a
            > locally built package, but other previously installed binary packages will
            > not be able to see the new version if you do that.
            >
            > I'll bet there is a binary of the new release available somewhere for your
            > distro.
            >
            > Rick Kunath, k9ao
            >
          • sjs50613
            Does anyone have a Fedora 10 rpm or binary for hamlib-1.2.9 that they would share? Steve AK0M
            Message 5 of 9 , Mar 26, 2009
            • 0 Attachment
              Does anyone have a Fedora 10 rpm or binary for hamlib-1.2.9 that they would share?

              Steve AK0M
            Your message has been successfully submitted and would be delivered to recipients shortly.