I'm setting up a new system with Slackware 11. After downloading and installing all the official patches for Slackware 11 (stable) using slapt-get, I usually install a few programs. One of these is ddd (digital display debugger) which is basically a graphical frontend to gdb. However, this time, when I go to compile ddd, I get the following error:

/usr/X11R6/include/X11/VendorP.h:87: error: previous declaration of 'VendorShellClassRec vendorShellClassRec' with 'C++' linkage
/usr/X11R6/include/Xm/VendorSP.h:58: error: conflicts with new declaration with 'C' linkage

Does this mean that something broke in the header files during the last patch to X11? This is about the 15th program that I've compiled from source after all the updates and after installing gcc-4.1.2, and the first one to have problems. Even crazy libraries like ATLAS, LAPACK, and fftw have gone in painlessly.

In case it's a problem with something else I've done, I'm compiling this with a hand compiled gcc-4.1.2 compiled with the following options:

Configured with: ../gcc-4.1.2/configure --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --enable-languages=c,c++,fortran,objc,java,obj-c++,treelang --target=i686-slackware-linux --host=i686-slackware-linux --with-tune=prescott --with-arch=prescott --with-cpu=prescott --prefix=/usr

And I have CFLAGS="-mtune=prescott -O2"

The only system changes that aren't part of the official Slackware 11 are gcc-4.1.2 and kernel-2.6.20.4.

Well, gcc4 doesn't like some things - maybe this is one of them. Aside from that little bit, no idea.

thanks for the tip.

gcc it is. when I compile it with gcc-3.4.6 that comes with Slackware 11 everything goes nice and smooth. However, when I look at the two header files that gcc 4.1.2 complains about, there are different declarations in them:

-----
/usr/X11R6/include/X11/VendorP.h:87:

externalref VendorShellClassRec vendorShellClassRec;
-----
-----
/usr/X11R6/include/Xm/VendorSP.h:58:

XMLIBEXPORT extern VendorShellClassRec vendorShellClassRec;
-----

They do LOOK different, but I don't know enough about the guts of X (x.org6.9.0) to tell if the difference is significant. Is there a flag for gcc-4.1.2 that makes it insensative to this sort of thing? Sorry, all I really know about programming is how to make C do some number crunching.

I notice that -current has moved up to gcc-4.1.1 ... is this sort of thing likely to become a common problem when I move on to 12 once it's released?

This is identical to the Xorg-7.3 RC headers in -current (which *definitely* build on gcc4).

Again, this is identical to what's in -current.

I have no idea - I'm guessing that whatever is including these headers is doing something with them that gcc4 doesn't like.

Well, I don't know how *common* it will be, but it's certainly a real possibility. In fact, I'll quote
http://slackware.osuosl.org/slackwar...nt/UPGRADE.TXT

The upgrade to gcc-4.x is likely to cause problems with building some software
from source. Please complain to the upstream maintainers...

OK, now I just feel ignorant. Does upstream maintainers mean Patrick, the gcc team, or the x.org guys?

I should also mention that I have another box that I goof around on that has bits of -current and bits of hand compiled stuff and I didn't run into this problem. The only difference is possibly the order that stuff was install when I put ddd on that one. I even toyed with installing the new modular x on that and decided to wait until Pat Volkerding figures it out since he's more likely to know what he's doing. Just to confirm what you said about the new x compiling with gcc 4 (or at least 4.1.1, which is what is currently in current). Can't wait for 12 - I've been waiting to tinker with compiz or beryl for a while now.

For example, if you're trying to compile wine [1], and it errors out with gcc4 but builds fine with gcc3, then you should complain to the wine developers.

[1] wine builds fine on gcc4, so don't anybody go complaining to them