/libexec/ld-elf.so.1: Shared object "libjpeg.so.9" not found

rebuild (pkg_delete -f /var/db/pkg/imlib[1 or 2 or both] ) both imlib
rebuild xli
rebuild lib* that had versions bumped
rebuild jasper if installed
grep libjpeg /usr/local/bin | hgrep Binary
...
(more complete instructions in another post or two recently
probably.) The instructions above are just a rough draft, but
may save you time if you know how to rebuild individual ports
in parallel, etc. (You should probably learn that also for
the next time the UPDATING do not do a complete upgrade for
a particular machine)
 
SirDice said:
Just a note, you should NOT do this. Doing this can seriously bite you some day.

Try and resolve the dependencies. Your best bet is to rebuild all the ports that are complaining about the missing libjpeg.so.9.
Click to expand...

Why not? I do this for years. and never had any trouble with it. In case something doesnt work, I can always remove the symlinks, but I never needed to, never seen any program complaining about using a library newer than the version it depends on.

Otherwise it would not be possible to play with the latest software without having to upgrade everything to -CURRENT or learn to use chroot/jails/emulation/multiboot to do your testing.

Just let's not make it too difficult for new users.
In my opinion it's a serious waste of time to rebuild and reinstall everything just because some libs have newer versions installed.
 
The latest portsnap run gave me 3000+ patches compared to the one of twelve hours ago. Looks like it concerns a lot of ports with jpeg dependencies, so this might be the 'bump all' moment for libjpeg.so.10. I guess people having trouble with libjpeg should update their ports and then repeat the actions mentioned in /usr/ports/UPDATING. Sorry for spamming this to six threads, but it seemed rather important with all the confusion out there ;)
 
24 hours rebuilding and I'm back on the road.

Wow I think I got mine working. It took about 24 hours using portmaster -Rr jpeg-7. It ran for about 3 hrs. then failed for /usr/ports/graphics/gd Error 1. I installed the port manually and restarted. About 5 hrs. later failed for /usr/ports/www/firefox3. Again, manual install and restart. Then it ran for a long time, 6-8 hours and failed for x11/kdelibs3. Install, restart now almost 24 hours later things seem to be working correctly. Thanks for all the help everyone.
 
DutchDaemon said:
Parallel installs are not advisable, unless you are dead certain that they won't be working on the same dependencies at the same time (race condition), clobbering the compilation of that dependency and nuking both ports.
Click to expand...

I thougt there was some sort of locking system on it. Never had any message from it, though.
But some ports cannot live together so it's still dangerous.
 
I often build/reinstall 4 ports at a time, seldom a
problem.
tty0
Code: 
make run-depends-list
tty1
make ...
tty2
make ...
tty3
make ...
then
each:
Code: 
make build && yell
(actually more complex than that, for quicker/smoother
completion, I've scripted most of it)
a few /yells/ and I can return to the builds from browsing or...
 
I hit exactly the same problem, but took a slightly different approach.

Since I was running the 7.0-Release I ftp'd to ftp3.us.freebsd.org, found my version, went into its ports/graphics directory and downloaded jpeg-6b_4.tgz.

On my machine I unpacked it and copied it to /usr/local/lib. Just be sure to delete the soft link if you made one according to the ealier posts. So far everything is working fine.
 
I would like some more clarity on why doing the following command is a bad idea:

ln -s /usr/local/lib/libjpeg.so.10 /usr/local/lib/libjpeg.so.9

It seems like its the only real solution provided, aside from rebuilding all affected ports.
 
The libjpeg people have decided that this version is not compatible with the previous version, so they bumped the shared library version number.

This may mean that just one almost unused function call has changed. It may also mean a lot of important function calls have changed.

You can make the link and if it works then it works and if it doesn't work then it doesn't. It may work today, it may not work tomorrow. Some functions may not work, the program may be unstable. It is difficult to tell.
But in any case, there is *probably* little chance of serious harm but there are no seatbelt or support. Use at own risk.

Me personally, I would just install both the new and old jpeg ports at the same time (Some minor hacking required).

MG said:
I thougt there was some sort of locking system on it. Never had any message from it, though.
But some ports cannot live together so it's still dangerous.
Click to expand...

OpenBSD ports do locking, and you can safely build any number of ports at the same time.
FreeBSD doesn't do any locking.
 
I would recommend using libmap.conf or ** rebuild ports that fail **

This way they would compile against the updated library
 
A possibility to deal with linjpeg.so.10 when it is disappeared from the system

A few days ago I was installing VLC media player, and after that KDE did not work anyway, the problem was that libjpeg.so.10 disappeared from /usr/local/lib; KDE could not start up.

Reading the posts related with this issue I found several solutions to fix it, and working around, in example making a symbolic link as is stated in several posts solved the problem but not completely. Then I took another way to solve the problem. I've installed the system from the beginning in a virtualized folder, then copied libjpeg.so.10 and libogg.so.6 to a safe place outside this folder and copied again these libraries to my original damaged system. I made a copy of theses libraries in a safe place in my original system too, as a backup from restoring them again if something wrong happens in future again.

I have tested KDE and everything was OK. I have deleted my virtualized system, and that was all the work. I feel this is a possibility if you have a way to work around by using some virtualizing software.
 
As stated below....on the post of MG:

Maybe there's a newer version in /usr/local/lib.

ln -s /usr/local/lib/libjpeg.so.10 /usr/local/lib/libjpeg.so.9

This is applicable in a general way. And works fine.

I had a problem with Amarok and Aqualung, the same you write on here. But it was with libmodplug.so.0.

In my /usr/local/lib appeared libmodplug.so, so I made a symbolic link.

ln -s /usr/local/lib/libmodplug.so.0 /usr/local/lib/libmodplug.so.0

Everything is working fine now. Amarok and Aqualung play mp3 perfectly.
 
So far, I've been able to straighten these things out by updating or rebuilding the programs or libraries that can't find the old version of a shared object.

However, in this case I have a bit of a hard time finding out what this would be - somewhere along the way I seem to have found a hint to ld or rather, binutils. However, I'm not absolute sure.

Is there any easier way to determine by which port a given library was installed?

regards,
Frank,
currently busy with libgcrypt-related rebuilds
 
Now that yielded nothing on ld.elf.so.1
That in turn led me the right track, and I found the answer in /usr/src/libexec/rtld-elf.
Silly of me to think that something from the base system should depend on a port...

Anyway, you live, you learn. DutchDaemon, remind me to buy you a beer if our paths should ever cross :)
 
May be pkg_tree is a good one...

Hello Frank

You posted this...
Is there any easier way to determine by which port a given library was installed?

I think that pkg_tree is a good tool because displays the name of the package and a sub-tree of related dependencies.

It is in "ports management", but I believe I've installed using "pkg_add -r".


Code: 
Here a chunk from the output...

$ pkg_tree| more

ORBit2-2.14.17
|\__ python26-2.6.6_1
|\__ perl-5.10.1_3
|\__ pkg-config-0.25_1
|\__ pcre-8.12
|\__ libiconv-1.13.1_1
|\__ gettext-0.18.1.1
|\__ glib-2.26.1_1
|\__ gamin-0.1.10_4
|\__ gio-fam-backend-2.26.1
 \__ libIDL-0.8.13
OpenEXR-1.6.1_2
|\__ pkg-config-0.25_1
 \__ ilmbase-1.0.1_1
Xaw3d-1.5E_3
|\__ xextproto-7.1.1
|\__ kbproto-1.0.5
|\__ pkg-config-0.25_1
|\__ xproto-7.0.16
|\__ libXau-1.0.6
|\__ libXdmcp-1.0.3
|\__ libICE-1.0.7,1
|\__ libSM-1.1.1_3,1
|\__ libpthread-stubs-0.3_3
|\__ libxcb-1.7
|\__ libX11-1.3.6,1
|\__ libXt-1.0.9
|\__ libXext-1.1.2,1
|\__ libXpm-3.5.7
 \__ libXmu-1.0.4,1
a2ps-letter-4.13b_4
 \__ perl-5.10.1_3
aalib-1.4.r5_4
|\__ kbproto-1.0.5
|\__ pkg-config-0.25_1
|\__ xproto-7.0.16
|\__ libXau-1.0.6
|\__ libXdmcp-1.0.3
|\__ libpthread-stubs-0.3_3
|\__ libxcb-1.7
 \__ libX11-1.3.6,1
....
....

Use "more" to manage the output or send the output to a file
 
You must log in or register to reply here.
Back
Top