libgdk-x11-2.0.so.0: Undefined symbol "shmctl"

I just installed FreeBSD 7.4 (x-kern-devel). I've been installing 7-Stable packages after the instsallation and upgrading ports in the porcess. (Due to the fact that the latest release of xorg is giving me a blank screen =P)

Anyhow, when I try to startx with xfce4, run firefox3, or any other app besides fluxbox (the only one working) I get the following error mesasge

Code:
/libexec/ld-elf.so.1: /usr/local/lib/libgdk-x11-2.0.so.0: Undefined symbol "shmctl"

Not sure which port this particular file belongs to, so I'm unable to install/upgrade. Any advice?

Thanks,
Tzun
 
I got exactely the same problem after deinstalling all packages from a 7.2-release installation and installing everything again from 7-stable packages. Even starx won't work displaying the above message. In my opinion a lot of stable-packages are just crap/wrongly compiled or something. No matter with what release in the past I have always encountered problems when trying to use them. Sometimes even release packages on an install DVD were affected and had to be recompiled from ports, after finding a solution in some forum (once it was nspr, then metacity, and now this...).
I wonder why this keeps happening with the official packages. This is a very bad thing and affects the use of FreeBSD severely.
What can/should be done in the future, that all packages come compiled without failures?
 
cabriofahrer - have you recently recompiled your kernel? I got the same issues after kernel rebuild, anyway I didn't find the reason, and way to fix it other than recompiling applications from ports..
 
No, I haven't. But if you say that it works after reinstalling from ports that just is another proof for my theory that many packages are just broken. Which means that you can never rely on setting up a new system using stable-packages that actually works.
And I really don't feel like installing xorg/kde/ or gnome from ports. That what packages are actually for.
 
I got now some conclusions about all that. I rebuild the kernel, because there was an update to 7.2-p4 and what was special about it: the update came additionaly with the upgrade of libc library, now issueing
Code:
objdump -T /lib/libc.so.7 | grep shmctl
prints
Code:
00045f64  w   DF .text	00000000  FBSDprivate_1.0 _shmctl
00045f64  w   DF .text	00000000  FBSD_1.0    shmctl
00045f64 g    DF .text	0000000a  FBSDprivate_1.0 __sys_shmctl
whereas the same for
Code:
objdump -T /usr/local/lib/libgdk-x11-2.0.so.0 | grep shmctl
gave
Code:
00000000      DF *UND*	00000000  FBSD_1.1    shmctl
Then after rebuilding x11-toolkits/gtk20 from ports libgdk library was linked against local /lib/libc.so.7 and the proper object version 1.0 is recognized. It occurs for all packages that are giving the "undefined symbol 'shmctl' " error. Other way to fix it would be an upgrade of libc coming with the proper symbol versioning as covered by http://people.freebsd.org/~deischen/symver/freebsd_versioning.txt

Anyway there is someone to be blamed for all the confusion about it...
 
Today I tried a freebsd-update fetch install on a fresh installed FreebSD 7.2-System. That gives you 7.2-p4 or something like that, an update of the kernel is also performed as I understand.
But when installing packages from 7-stable you still get the same problem. It looks like you just cannot rely on installing stable-packages on a release-system, no matter what you do.
So either you stick to the old release-packages or you upgrade from ports, or you upgrade to 7-stable with makeworld (or something like that, because binary-upgrade with freebsd-update does only upgrade to releases and candidates, but not stable), is that so?
Aren't there any sites with actual versions of packages for release-versions of FreeBSD?
 
Apparently that seems to be right, the problem arises when mixing packages from STABLE branch with RELEASE version of system. Can be fixed after moving system to STABLE branch (cvsup and make buildworld), or rebuilding the packages causing errors from ports.
 
You don't even need to mix stable-with release-packages. A complete userland environment by stable packages only in a releas base-system will cause that trouble. Of course you can reinstall packages causing trouble with ports, but in order to do that you first need to find out which packages are causing that problem.
And upgrading the basis-system to stable is no good, because then neither freebsd-update nor a sysinstall-upgrade of a later release version will work then. This is very unsatisfactory.
Why can't we just get provided with up to date release-packages for people who want to stick with their FreeBSD-Release-Version until a new release comes out, which actually is the recommended thing to do for production use???
 
Back
Top