The issue of how to correct programs that rely upon libjpeg.9.so after updating to libjpeg.10.so has apparently been addressed at:
http://forums.freebsd.org/showthread.php?t=5906 "/libexec/ld-elf.so.1: Shared object "libjpeg.so.9" not found"
This has been a problem because routine portmaster/portupgrades are breaking builds (I.E. requiring major upgrades that take low end production systems out of operation for a few days and require moderate user interaction). From the posts I see it does not look like the issue has been resolved. (E.G. that the solution posted at http://forums.freebsd.orgshowthread.php?p=33699 "graphics/gd seems to be broken" does not work for some.) I seek additional information regarding this issue.
For example, after upgrading jpeg-7 (which is necessary for a lot of applications I use, including KDE3 & KDE4 apps) and rebooting, kdm fails to start with the following message:
I have questions with the following issues:
A little background about my build first.
Installed from FreeBSD 7.1 in January w/ KDE3 from packages. Installed KDE4 from ports. Installed many userland applications relying on libjpeg. Upgraded to FreeBSD 7.2 in May. Rebuilt KDE4.2, updated KDE3 & all ports. Portsnapped August 1 and started updating around August 20th.
I used only portmaster, not portupgrade, for port managment. Since initial install w/ kde3, have not used packages collections, only building ports.
set sysctl some time ago as per an early UPDATING or port post install message.
Question #1:
The easiest solution appears to simply link libjpeg.so.9 to libjpeg.so.10 using the command:
This works by creating a pseudo libjpeg.9.so so that anything needing libjpeg.9.so will think libjpeg.10.so is libjpeg.9.so. Apparently, this works with libjpeg because libjeg is generally backwards compatible.
However, I have not used this approach because Sir. Dice says "Just a note, you should NOT do this. Doing this can seriously bite you some day."
What specifically is the harm in making this link? Would not future system upgrades silently obliterate references to libjpeg.so.9 replacing them with references to libjpeg.so.10? Not as a general matter, but, specific to this instance, how can this link come back to hurt you?
I am anxious to try this solution because basically a complete rebuild of kde3 & kde4, ETC, is impracticable. On an Asus EEE Box, it takes a couple hours just to check dependencies before starting to build ... I have +IGNOREME with some leaf ports (not dependent upon other ports, e.g. openoffice) and now that portmaster -u option has been depreciated, I can't find a way to automatically accept the default [n] to ignore ports. Is there a way to run portmaster so it automatically assumes ignore ports marked ignore without user interaction? (er, question 3.5)
Question #2:
Why do we upgrade ports that rely on libjpeg when shouldn't we be upgrading/rebuilding ports that libjpeg.10.so depends upon?
The culprit, in what seems to break builds, is the installation of jpeg-7 which replaces libjpeg.9.so with libjpeg.10.so. I understand how its necessary to rebuild all the ports that depend upon jpeg--7. Updating says that its necessary to run portmaster -r jpeg- or portupgrade to rebuild all the dependencies.
what about rebuilding all the ports that libjpeg relies upon. Arent these the ones that refer to the older libjpeg.9.so? Wouldn't updating those ports (assuming the ports are up to date and now refer to libjpeg.10.so). I want to update all ports/systems that are dependent upon libjpeg.so.9 and update those.
How do I tell what ports are looking for libjpeg.so.9? I can't use ldd for libjpeg.so.9 because it's not on my system. should I be using 'find' to search through all the dependency information in /usr/ports to locate applications that rely upon jpeg or jpeg-7? If so, what is the find command to use?
When I try to run a program that needs a libjpeg.9.so, I get a message, like,
"/libexec/ld-elf.so.1: Shared object "libjpeg.so.9" not found, required by <insert your favorite program here>".
So, I've identified ld-elf.1.so, but, how do I find out what port installs ld-elf.1.so (xorg?)?
Question #3:
UPDATING refers to three commands, portmaster -r jpeg*, portmaster -w, and portupgrade.
Builds have failed a few times using portmaster -r jpeg-7.
I.E.
I am using the -rR option for subsequent attempts (when I run portmaster -r jpeg-7 after thinking I've fixed the reason a prior run failed) and I haven't come across documentation on it. The first question portmaster -rR /var/db/pkg/[name] ask is:
There are 'install completed' flags from a previous portmaster -[rf] run, delete these[n].
I assume you don't delete them .. that you keep them so that portmaster will know which ports have been rebuilt. Do these 'install complete' flags apply only to runs of portmaster -[rf]R within the jpeg-7 port directory or will the flags interfere with subsequent rebuilds using portmaster -a or with portmaster -r on other ports?
The next question portmaster -[rf]R is:
Enable the R option.
I assume yes, enable R option to skip building ports marked 'install complete' on prior runs.
I have never used the -w option with portmaster and haven't come across complete documentation on it's features. Is this just an option to save old libraries or does it actually do something else besides saving old libraries?
Question #4:
jpeg vrs. jpeg-7? I thought graphics/jpeg was now at jpeg-7 but ports dependent upon jpeg failed to build until I installed jpeg-7.
Question #5:
At what point in the process of updating libjpeg.9.so to libjpeg.10.so is it necessary or desireable to run portmaster --check-depends, portmaster --check-db? I run these before I run portsnap fetch extract. Does it help or hurt to run these commands to help diagnose or fix libjpeg.9.so links when you are in the middle of a broken build?
Question #6
I ran into these problems 4+ weeks ago but have only gotten around to addressing it now. Would it be useful to run portsnap fetch extract again, then do portmaster -aD and see if the problem has been corrected in the last couple of weeks? Or, would this cause problems and I would be better off continuing to try to build out the system with ports fetched previously? What would sys admins do -- keep trying to find a solution, or, hope and pray its been fixed?
http://forums.freebsd.org/showthread.php?t=5906 "/libexec/ld-elf.so.1: Shared object "libjpeg.so.9" not found"
This has been a problem because routine portmaster/portupgrades are breaking builds (I.E. requiring major upgrades that take low end production systems out of operation for a few days and require moderate user interaction). From the posts I see it does not look like the issue has been resolved. (E.G. that the solution posted at http://forums.freebsd.orgshowthread.php?p=33699 "graphics/gd seems to be broken" does not work for some.) I seek additional information regarding this issue.
For example, after upgrading jpeg-7 (which is necessary for a lot of applications I use, including KDE3 & KDE4 apps) and rebooting, kdm fails to start with the following message:
Code:
pandora# kdm
Updating KDM configuration
/libexec/ld-elf.so.1: Shared object "libjpeg.so.9" not found, required by "genkdmconf"
/libexec/ld-elf.so.1: Shared object "libjpeg.so.9" not found, required by "kdm-bin"I have questions with the following issues:
- (1) ln -s /usr/local/lib/libjpeg.so.10 /usr/local/lib/libjpeg.so.9 --- why the f__ not?
- (2) how to find/update ports dependent upon libjpeg.so.9
- (3) how to run portmaster with the -R option
- (3.5) non-interactive way to deal with ports marked +IGNOREME when doing portmaster -aD?
- (4) graphics/jpeg vrs. graphics/jpeg-7
- (5) safe times to check ports database and dependencies
- (6) do more portsnap fetch extract and hope it's fixed?
A little background about my build first.
Code:
# uname -a
FreeBSD pandora.local 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009 root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386Installed from FreeBSD 7.1 in January w/ KDE3 from packages. Installed KDE4 from ports. Installed many userland applications relying on libjpeg. Upgraded to FreeBSD 7.2 in May. Rebuilt KDE4.2, updated KDE3 & all ports. Portsnapped August 1 and started updating around August 20th.
I used only portmaster, not portupgrade, for port managment. Since initial install w/ kde3, have not used packages collections, only building ports.
set sysctl some time ago as per an early UPDATING or port post install message.
Question #1:
The easiest solution appears to simply link libjpeg.so.9 to libjpeg.so.10 using the command:
Code:
ln -s /usr/local/lib/libjpeg.so.10 /usr/local/lib/libjpeg.so.9This works by creating a pseudo libjpeg.9.so so that anything needing libjpeg.9.so will think libjpeg.10.so is libjpeg.9.so. Apparently, this works with libjpeg because libjeg is generally backwards compatible.
However, I have not used this approach because Sir. Dice says "Just a note, you should NOT do this. Doing this can seriously bite you some day."
What specifically is the harm in making this link? Would not future system upgrades silently obliterate references to libjpeg.so.9 replacing them with references to libjpeg.so.10? Not as a general matter, but, specific to this instance, how can this link come back to hurt you?
I am anxious to try this solution because basically a complete rebuild of kde3 & kde4, ETC, is impracticable. On an Asus EEE Box, it takes a couple hours just to check dependencies before starting to build ... I have +IGNOREME with some leaf ports (not dependent upon other ports, e.g. openoffice) and now that portmaster -u option has been depreciated, I can't find a way to automatically accept the default [n] to ignore ports. Is there a way to run portmaster so it automatically assumes ignore ports marked ignore without user interaction? (er, question 3.5)
Question #2:
Why do we upgrade ports that rely on libjpeg when shouldn't we be upgrading/rebuilding ports that libjpeg.10.so depends upon?
The culprit, in what seems to break builds, is the installation of jpeg-7 which replaces libjpeg.9.so with libjpeg.10.so. I understand how its necessary to rebuild all the ports that depend upon jpeg--7. Updating says that its necessary to run portmaster -r jpeg- or portupgrade to rebuild all the dependencies.
what about rebuilding all the ports that libjpeg relies upon. Arent these the ones that refer to the older libjpeg.9.so? Wouldn't updating those ports (assuming the ports are up to date and now refer to libjpeg.10.so). I want to update all ports/systems that are dependent upon libjpeg.so.9 and update those.
How do I tell what ports are looking for libjpeg.so.9? I can't use ldd for libjpeg.so.9 because it's not on my system. should I be using 'find' to search through all the dependency information in /usr/ports to locate applications that rely upon jpeg or jpeg-7? If so, what is the find command to use?
When I try to run a program that needs a libjpeg.9.so, I get a message, like,
"/libexec/ld-elf.so.1: Shared object "libjpeg.so.9" not found, required by <insert your favorite program here>".
So, I've identified ld-elf.1.so, but, how do I find out what port installs ld-elf.1.so (xorg?)?
Question #3:
UPDATING refers to three commands, portmaster -r jpeg*, portmaster -w, and portupgrade.
Builds have failed a few times using portmaster -r jpeg-7.
I.E.
Code:
# portmaster -r jpeg-7
<snip>
creating libgtkmm-2.4.la
(cd .libs && rm -f libgtkmm-2.4.la && ln -s ../libgtkmm-2.4.la libgtkmm-2.4.la)
gmake[5]: Leaving directory `/usr/ports/x11-toolkits/gtkmm24/work/gtkmm-2.16.0/gtk/gtkmm'
gmake[5]: write error
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory `/usr/ports/x11-toolkits/gtkmm24/work/gtkmm-2.16.0/gtk/gtkmm'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory `/usr/ports/x11-toolkits/gtkmm24/work/gtkmm-2.16.0/gtk'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/usr/ports/x11-toolkits/gtkmm24/work/gtkmm-2.16.0/gtk'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/ports/x11-toolkits/gtkmm24/work/gtkmm-2.16.0'
gmake: *** [all] Error 2
*** Error code 1
Stop in /usr/ports/x11-toolkits/gtkmm24.
===>>> make failed for x11-toolkits/gtkmm24
===>>> Aborting updateI am using the -rR option for subsequent attempts (when I run portmaster -r jpeg-7 after thinking I've fixed the reason a prior run failed) and I haven't come across documentation on it. The first question portmaster -rR /var/db/pkg/[name] ask is:
There are 'install completed' flags from a previous portmaster -[rf] run, delete these[n].
I assume you don't delete them .. that you keep them so that portmaster will know which ports have been rebuilt. Do these 'install complete' flags apply only to runs of portmaster -[rf]R within the jpeg-7 port directory or will the flags interfere with subsequent rebuilds using portmaster -a or with portmaster -r on other ports?
The next question portmaster -[rf]R is:
Enable the R option.
I assume yes, enable R option to skip building ports marked 'install complete' on prior runs.
I have never used the -w option with portmaster and haven't come across complete documentation on it's features. Is this just an option to save old libraries or does it actually do something else besides saving old libraries?
Question #4:
jpeg vrs. jpeg-7? I thought graphics/jpeg was now at jpeg-7 but ports dependent upon jpeg failed to build until I installed jpeg-7.
Question #5:
At what point in the process of updating libjpeg.9.so to libjpeg.10.so is it necessary or desireable to run portmaster --check-depends, portmaster --check-db? I run these before I run portsnap fetch extract. Does it help or hurt to run these commands to help diagnose or fix libjpeg.9.so links when you are in the middle of a broken build?
Question #6
I ran into these problems 4+ weeks ago but have only gotten around to addressing it now. Would it be useful to run portsnap fetch extract again, then do portmaster -aD and see if the problem has been corrected in the last couple of weeks? Or, would this cause problems and I would be better off continuing to try to build out the system with ports fetched previously? What would sys admins do -- keep trying to find a solution, or, hope and pray its been fixed?