DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Packages and Ports

OpenBSD Packages and Ports Installation and upgrading of packages and ports on OpenBSD.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 23rd May 2011
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,027
Default library mismatch for snapshots epdfview

In the snapshots i386 epdfview package

http://ftp.openbsd.org/pub/OpenBSD/s...ew-0.1.7p7.tgz

the +CONTENTS file says there's a library dependence of

@wantlib stdc++.51.0

but the included binary bin/epdfview wants a different library:

epdfview: can't load library 'libstdc++.so.50.0'

Oh dear, what's to become of this?
Reply With Quote
  #2   (View Single Post)  
Old 23rd May 2011
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Banned
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Default

libstdc++ was bumped relatively recently, you need to install a new snapshot.. I don't see this problem on my system, with a recent snapshot and epdfview-0.1.7p7.

The problem is on your end.
Reply With Quote
  #3   (View Single Post)  
Old 24th May 2011
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,027
Default

Quote:
Originally Posted by BSDfan666 View Post
libstdc++ was bumped relatively recently, you need to install a new snapshot.. I don't see this problem on my system, with a recent snapshot and epdfview-0.1.7p7.

The problem is on your end.
Thanks for the reply. I have a fairly recent snapshot, with a clean install,

OpenBSD dirty.lan 4.9 GENERIC#75 i386

It has only the stdc++51 library, and epdfview refused to run because it wants an older library "50", despite what the +CONTENTS says. So I think my snapshot is new enough.

If I link in a kluge libstdc++.so.50.0 to the existing "51", it will run. Since it runs for you, are you sure you don't have an old "50" library hanging around as cruft?

I had this problem with several packages and that's how I noticed the version bump. The packages were corrected soon in most cases (e.g., fluxbox, gnuplot, xpdf), but epdfview only appears corrected but the binary still requires the old library "50" AFAICT.
Reply With Quote
  #4   (View Single Post)  
Old 24th May 2011
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,027
Default

Update: I just checked the strings in the epdfview binary, and it does say libstdc++.so.51.0, consistent with the +CONTENTS. So I must have a problem with some other dependency I think not being bumped up. I will track it down. Thanks again.
Reply With Quote
  #5   (View Single Post)  
Old 24th May 2011
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Banned
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Default

It is never a good idea to link shared libraries with different major numbers, it is meant to indicate ABI breakage.

Indeed, you should make sure you've cleanly updated.. even if that means deleting every package and reinstalling.
Reply With Quote
  #6   (View Single Post)  
Old 24th May 2011
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,027
Default

Quote:
Originally Posted by BSDfan666 View Post
It is never a good idea to link shared libraries with different major numbers, it is meant to indicate ABI breakage.
Yeah, I didn't want to leave it in that state ... but it can be a useful brief experiment to verify a problem. Link is gone.

Quote:
Indeed, you should make sure you've cleanly updated.. even if that means deleting every package and reinstalling.
I grepped the +CONTENTS files under /var/db/pkg and came up with 60MB of packages still wanting the old library. Will have to download the updates when I have time. Good idea to de- and re-install everything.

Just my luck I guess the packages (which I downloaded some time after installing the snapshot) were not yet up to date with it. I guess this is a risk of -current.

Looks like this should be workable now, thank you again for your help.

EDIT: Trying to recall the sequence of events, the lack of sync may have had more to do with mirror lag than -current. FWIW.

Last edited by IdOp; 24th May 2011 at 03:54 AM.
Reply With Quote
  #7   (View Single Post)  
Old 24th May 2011
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 3,318
Default

Quote:
Originally Posted by IdOp View Post
...I guess the packages (which I downloaded some time after installing the snapshot)...
Since we have a number of newbies of late who are venturing into the -current world, I'm calling out this fact -- packages, just like source, have to be matched to the snapshot installed.

Irregardless of whether installing a snapshot is the end goal or whether the snapshot is merely a baseline for installing source & building the system from a fully sanctioned code base (see Section 5.1 for more information...), matching kernel to userland to 3rd party applications is very important. Failure to synchronize everything will result in peculiarities ranging from subtle to overt.
Reply With Quote
  #8   (View Single Post)  
Old 24th May 2011
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Banned
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Default

Someone who is paying attention to changes of course would notice events in the kernel/userland that would require bulk rebuilds of ports.. i.e: major library bumps, kernel ABI changes.

As for synchronizing snapshots and packages, that's not always possible, they are built at different times.

An unofficial site for tracking this: http://www.rhaalovely.net/up2date.html
Reply With Quote
  #9   (View Single Post)  
Old 24th May 2011
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 3,318
Default

Quote:
Originally Posted by BSDfan666 View Post
As for synchronizing snapshots and packages, that's not always possible, they are built at different times.
Correct, but anyone who installs a snapshot, waits a few weeks, & then updates packages is taking undue chances. Install a newer snapshot first.
Reply With Quote
Old 24th May 2011
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

There was a recent thread on this in misc@. It was quite active, with 53 responses to the original post. You may find the entire thing helpful, so here is the link to the first post in the thread.

I will quote from Ted Unangst, who posted this in reply in the midst of discussion:
Quote:
Today libpng has version X, gtk version Y, and firefox version Z. You
install these packages.

In one week, libpng is updated to version X+1 and firefox is updated
to version Z+1. You update. The gtk version has not changed, it will
not be upgraded. Now firefox is linked to png X+1 and X (via gtk).
Hilarity ensues. A newly built gtk will be linked against png X+1 and
will work correctly.
Because any particular snapshot is not synced to snapshot packages, users of snapshots must not only ensure the packages they install are within sync with the snapshot, they must also ensure they are in sync with each other. Snapshot packages are bulk built, but the mirror you are using may be in the midst of an update at the time you are using it.
Reply With Quote
Old 24th May 2011
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,027
Default

Thanks to everyone for the further helpful comments, they're much appreciated, and the thread linked by jggimi looks very relevant, I'll go through it soon.

I should clarify a bit the sequence of events because something I wrote above was confused (sorry about that). My statement that I downloaded the packages after the system snapshot is incorrect, and doesn't fully fit with the observed problem. I must have had in mind installing the packages after the snapshot (as must be) but that is of course irrelevant, what matters is when the packages were compiled relative to the snapshot. So here is what happened.

1) I downloaded the packages from a mirror (mirror.ece.vt.edu) to a shell account, bundled them up and put them on a website.

2) Within 24 hours of 1) I went to download that bundle and decided to get a new system snapshot. Here, I checked ftp.openbsd.org to see what the latest snapshot was. I was going to download it from mirror.ece.vt.edu, but the one there was still older, so I got the latest from the Chicago mirror.

So you can see that due to the order of events, mirror lag, and the very questionable decision to do #2, it ended up with the packages being older than the snapshot, and by bad luck the library bump must have occurred in that gap. The rest is history.

My takeaway from this is that, to minimize the chances of lack of sync, one should download the packages and snapshot from the same site at the "same time". If I want the latest, find a mirror that has the latest snapshot and use its packages too. Hope that is about right.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenBSD OpenBSD 4.7 beta snapshots J65nko News 0 29th January 2010 08:02 PM
Tracking OpenBSD snapshots with some simple sh scripts J65nko Guides 3 2nd December 2009 04:55 AM
Script to update NetBSD using snapshots s0xxx Guides 5 23rd November 2009 04:30 PM
SHA256 replaces MD5 in OpenBSD snapshots J65nko OpenBSD General 3 6th May 2009 04:36 PM
gem Collisions, duplex mismatch? tad1214 FreeBSD General 1 8th July 2008 02:32 AM


All times are GMT. The time now is 09:31 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick