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.

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.

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.

...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.

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.

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.