Not very happy about this "libobjc.so.2" problem

[Niatross]

Why do you say the following:

If you want to buildworld with a better compiler than gcc42, you should try clang

Why can't you buildkernel with clang? Why do you limit clang to buildworld only?

 

[jb_fvwm2]

One other method, maybe quicker.

As a general "how this happens", an example scenario.

The user installs a standard system including X and Firefox. graphics/png is installed as a dependency; Firefox and many other programs need it.

Later on, a new version of png comes out and the port is upgraded. The user installs this new version, but does not rebuild everything that depends on png. All those programs are still looking for an old library that went away when png was upgraded.

So what should be done? Several things:

1. Before upgrading or installing a new port, first read /usr/ports/UPDATING. You only need to pay attention to entries that have been added since the last time you installed or upgraded. Don't pick and choose, just look at all of them. If any apply to your system (ports you have installed or instructions that apply to all systems), do them in order from oldest to newest. Don't install or upgrade anything until you've caught up with the latest UPDATING changes.

2. When upgrading installed applications, use a port upgrade tool, either ports-mgmt/portmaster or ports-mgmt/portupgrade (or the -devel version). These programs will look for programs that depend on the port being upgraded and rebuild them. portmaster does it automatically, portupgrade has -r.

To fix the problems in post #1, figure out what port provided the missing libraries. Install or reinstall that port, and force the port upgrade program to rebuild everything that depends on it. My first guess would be lang/gcc46 for most of them.

After trying pkg_libchk, it reported a slew of ports which depended upon older libraries. Howsoever, beginning the recompile of most of them I ran across the problem of many ports not having been rebuilt after the pcre bump. As I had too many installed to rebuild them all[1], one can write a short list (on paper of the ones one knows will be used, say, in the next year, and try running them without X running (at the command line). I found that several large multi-hour-compile ports needed only a minor dependency bump, while many other lesser ports needed a full recompile that would not have been guessed at otherwise.

[1] unless one has crafted some scriptable methodology; I know for a fact it can be done, but it may not be worth the while of anyone fixing such problems; it takes much less time to recompile a lesser number of ports (this way) than many more of them (if one has many installed.).

Sorry for the rough draft of a guide, though, and for it maybe not being the most convenient for those reading the thread who have only
maybe a third of the number of "desktop" ports installed.

 

[kpa]

Put up the full build log in for example pastebin, we can't even start to guess what is wrong with build if all the information is just "exit 1".