Has anyone compiled and ran openbox one 12.1?

I just installed 12.1, with xfce and fluxbox, and wanted to go to my old favorite, openbox. I downloaded openbox 3.4.7.2, untared, configured, made, and make installed. Running openbox gives me the error

openbox: error while loading shared libraries: libobrender.so.21: cannot open shared object file: No such file or directory

Any help? I'm on a fresh, clean installation, so I haven't changed anything yet about the slackware installation. I remember running openbox on 12.0 last year, but I have been away from my dear linux for a while.

Thanks!

One of the two main points there is impossible.
Either 1) you didn't compile openbox on your system, or 2) it's not a fresh clean installation.

Hahaha. Can't trick you, rworkman. You're right. It's fresh EXCEPT for my compilation and installation of openbox. That must be my problem right there! =P

There is an openbox slackbuild at SlackBuilds.org BTW. Obconf is there as well. I can confirm both work as expected on 12.1.

I may end up resorting to that, but I would rather fix this problem. It feels like my system is in some way broken if I can not compile openbox and use it myself. Nothing against packages, and I probably would have gotten the package had I thought of it first, but now that I know there is a problem I have a need to fix it rather than work around it. And if a new version comes out with features that I would like, I would like to be able to compile that myself.

Any ideas?

Well, there is no openbox package at SlackBuilds.org, of course. SlackBuilds.org contains slackbuild scripts that you use to compile your own package for your own system that you can easily upgrade later on with upgradepkg. It's just like compiling only better. :-) It's the same way PV makes official Slackware packages. And since I'm the maintainer of the openbox and obconf SlackBuilds at SlackBuilds.org, they are updated with each new upstream release. Check out the HOWTO and the FAQ at SlackBuilds.org. I know this still doesn't answer your question, but I just wanted to touch on that.

Did you do a _full_ Slackware fresh install before compiling Openbox?

Oh, okay. I thought slackbuilds was a slackware package site. Did you have to do anything special to get openbox to build when creating your slackbuild?

I went through all the menus, but the only things that I excluded were a few kde applications like koffice and such, games, and the other windowmanagers besides xfce and fluxbox.

If I build using the slackbuild I get this error when running openbox:

Openbox-Message: Failed to open the display from the DISPLAY environment variable.

To see what was done, check out the SlackBuilds at slackbuilds.org -- they're just text files.
openbox: http://slackbuilds.org/slackbuilds/1...box.SlackBuild
obconf: http://slackbuilds.org/slackbuilds/1...onf.SlackBuild

To actually build the package using the SlackBuilds, you'll need the other files included with the SlackBuild -- they're all in the .tar.gz package linked to at the page for each SlackBuild (search slackbuilds.org for openbox and obconf).

In the future, please include this information with your initial post -- without it, we have to assume you performed a full installation. It is entirely possible that the reason for future troubles is a missing dependency that is included in a full installation, and without disclosing that information no one would know to suggest that. It may not be the problem here, but just a note for the future.
How are you launching openbox? I'm not sure if `xwmconfig` will find openbox or not to allow you to select it as the default window manager, but it's worth a shot. Otherwise, you should have a ~/.xinitrc file that launches openbox. There is an xinitrc.openbox file included with the SlackBuild that you should be able to move to your home directory and rename .xinitrc. Then try launching it with a simple `startx`.

If that IS what you are doing, make sure no other X sessions are running. Are you using runlevel 3 or 4? You can *try* launching it with `startx -- :0` but I can almost guarantee that won't work.

Alright...

If I build with the slackbuild and use the xinitrc included, it now runs. Thank you.

If I build from source myself and use the same xinitrc, it has the error I posted in the first post of this thread. So my original problem is not solved, but I do have a working openbox.

I don't think that the lack of a couple of optional kde packages broke some sort of openbox dependency, though.

If it builds and works with the SlackBuild but not manually, then you're doing something wrong when you build it manually. The SlackBuild is simply a script -- you could perform every step manually if you want to accomplish the same result (and the app will build properly). It could be an option in ./configure that is not supported in a default Slackware setup or something like that. I'll break the SlackBuild down for you.
The above just makes sure that the correct permissions (root with 644 and 755) exist on all the files. If they're incorrect, and you install the package, it can really screw up your system (only certain users can access certain root directories like /etc or /usr). This is just preventing that from happening.
This is probably the key step that is preventing a proper build. The CFLAGS and CXXFLAGS variables optimize the build for your CPU architecture. For i486 (the default) CPUs, this means that both CFLAGS and CXXFLAGS are set to "-O2 -march=i486 -mtune=i686". The ./configure part is the most important. It determines where the compiled binaries are put, the location of any configuration directories, etc. Running `./configure --help` in the source directory should list all of the possible options. If you use the above options, it should work fine -- if you change the options, it *may* work depending on which options you choose and what you set them to.
This actually compiles the app and installs the binaries to the location specified by the $PKG variable. If you don't want to create a package and just want to install the files (I would discourage this, as it makes it more difficult to upgrade/uninstall the app should you ever wish to do so) you could remove the DESTDIR=$PKG option and it would just install the binaries to your system in the locations specified by the ./configure command.
This just strips the binaries, making them smaller. It shouldn't be necessary, but is almost always done (there is no need wasting space). It only VERY rarely has any negative impact on the binaries. Of course, this step cannot be easily done if you aren't using the DESTDIR variable, since the binaries will already be installed into your live system -- and therefore this command would either have no effect or try to strip every binary on your system (both of which are bad) depending on which directory you start the find commands in.
This just gzips any `man` pages installed by the app. Again, this step is not as easily done if you didn't specify the DESTDIR option.
This command just copies the xinitrc.openbox file to the correct location in the package and sets the proper permissions. If you are installing the app WITHOUT the DESTDIR variable, you'd have to manually copy the xinitrc.openbox file to /etc/X11/xinit/xinitrc.openbox. Note that this xinitrc files is NOT included with openbox. A ~/.xinitrc file containing exactly the contents of this file should work.
Just read the comments for that one -- it isn't required if you're using openbox as a standalone window manager. The rest of the SlackBuild is just package-specific (ie not required for a functional build), so I won't go through it.

If you perform the necessary steps outlined above (note that binary-stripping and compressing the man pages are probably not *required*, but are good form), you should create a functional openbox build. If you didn't specify a DESTDIR variable, it will be difficult to upgrade/remove openbox, but it should still work. I would still encourage creating packages.

For more information about writing SlackBuilds (my favourite compilation method, but even if you don't write SlackBuilds and want to type the commands manually without creating a package it'll still help to read the following) see here: http://slackwiki.org/Writing_A_SlackBuild_Script

The bottom line is that if you could create a working openbox package using the SlackBuild, your system isn't broken. There is no "magic" in this SlackBuild (some SlackBuilds for other apps need to have strange configuration options or odd commands to get stuff to work), so I can't see why a manual build wouldn't work properly if done right.

I was not supplying any options to ./configure. Why is it necessary to change those directories? Why are the defaults not the correct ones for slackware 12.1?

Most software uses a default prefix of /usr/local. In general it is best to specify these environment variables because some devs use different default directories.

Sometimes it doesn't matter so much, but sometimes other programs/libraries are expected to be in a certain place, so it can matter a lot. It's best to be consistent.

So in slackware is it best to always define the prefix as /usr?

That depends. The "official" Slackware apps are always installed in /usr, and so slackbuilds.org and most other repositories tend to install things in /usr as well. Some people like to keep all of their self-installed apps separate and choose to install things to /usr/local or /opt or something similar -- it depends on what you want to do. Installing to /usr/local should generally be fine anyway, but note that the ./configure options also included sysconfdir (/etc, the directory with system configurations) and localstatedir (/var), which may have made a difference.