Created attachment 1681 [details]
Copy of libudev.h from udev-135 (used in Slackware 12.2)

Attached is a copy of the libudev.h with the cranky define (refer to the build log errors).

Looks like the failure is due to an old udev version.  The TDE hardware library cannot be completely disabled as it provides functionality beyond the simple HAL hooks that were present in TDE < R14, however we should be able to support your udev version with a few #ifdefs.

Can you post the exact version of udev that ships with Slackware 12.2?

Thanks!

(In reply to comment #2)
> Looks like the failure is due to an old udev version.  The TDE hardware library
> cannot be completely disabled as it provides functionality beyond the simple
> HAL hooks that were present in TDE < R14, however we should be able to support
> your udev version with a few #ifdefs.
> 
> Can you post the exact version of udev that ships with Slackware 12.2?
> 
> Thanks!

Never mind, you posted the version number above.

See if adding this line:
#define LIBUDEV_I_KNOW_THE_API_IS_SUBJECT_TO_CHANGE 1
to the top of thdehardwaredevices.h allows the compilation to finish.

Created attachment 1682 [details]
Patch for older libudev.h

I tested your change in Slackware 13.0, which is a tad newer than 12.2. 13.0 uses udev-141.

Your change got past one error but I ran into another, that SW_VIDEOOUT_INSERT was not declared. I resolved that problem by moving 'BIT_IS_SET(switches, SW_VIDEOOUT_INSERT)' to inside the FIXME.

That got me to a new failure, that 'udev_monitor_filter_add_match_subsystem_devtype' was not declared. I searched libudev.h and that structure does not exist. To see this, refer to the attached copy of libudev.h.

I'm attaching a patch with the changes made thus far.

This bug report also affects Slackware 13.0.

Slackware 12.2 is approaching EOL but 13.0 will not be EOL for about another year.

(In reply to comment #5)
> This bug report also affects Slackware 13.0.
> 
> Slackware 12.2 is approaching EOL but 13.0 will not be EOL for about another
> year.

If udev_monitor_filter_add_match_subsystem_devtype is not defined resolving this report becomes impractical.  Can a newer version of udev be compiled on your Slackware boxes?

> Can a newer version of udev be compiled on your Slackware boxes?
Seems to negate the whole deal. With a newer udev version 12.2 no longer is 12.2 and 13.0 no longer is 13.0. I already had to build a newer version of cmake because Trinity requires 2.8.4 minimum.

That said, I built and installed udev-153 on Slackware 13.0. I don't want to use anything much newer than what was installed. I remember around version 161 (181?) or something like that many things changed with udev.

With udev-153, tdelibs built on 13.0 but I had to patch for SW_VIDEOOUT_INSERT, moving that snippet to inside the FIXME section.

tdebase FTBFS. The error:

=======================
[ 93%] Building CXX object nsplugins/viewer/CMakeFiles/nspluginviewer.dir/viewer.cpp.o
cd /dev/shm/tdebase.build/nsplugins/viewer && /usr/bin/c++   -DHAVE_CONFIG_H -O2 -march=i486 -mtune=i686 -ggdb -fvisibility=hidden -fvisibility-inlines-hidden  -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/opt/trinity/include -I/usr/include/tqt -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/dev/shm/tdebase.build/nsplugins/viewer -I/dev/shm/tdebase.build -I/dev/shm/tdebase/nsplugins -I/opt/trinity/include -I/usr/include/tqt -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include    -o CMakeFiles/nspluginviewer.dir/viewer.cpp.o -c /dev/shm/tdebase/nsplugins/viewer/viewer.cpp
/dev/shm/tdebase/nsplugins/viewer/viewer.cpp: In function 'int main(int, char**)':
/dev/shm/tdebase/nsplugins/viewer/viewer.cpp:252: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
/opt/trinity/include/tdeapplication.h:131: note: candidate 1: TDEApplication::TDEApplication(bool, bool, bool)
/opt/trinity/include/tdeapplication.h:271: note: candidate 2: TDEApplication::TDEApplication(int&, char**, const TQCString&, bool, bool, bool)
/dev/shm/tdebase/nsplugins/viewer/viewer.cpp:252: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
/opt/trinity/include/tdeapplication.h:131: note: candidate 1: TDEApplication::TDEApplication(bool, bool, bool)
/opt/trinity/include/tdeapplication.h:271: note: candidate 2: TDEApplication::TDEApplication(int&, char**, const TQCString&, bool, bool, bool)
make[2]: *** [nsplugins/viewer/CMakeFiles/nspluginviewer.dir/viewer.cpp.o] Error 1
make[2]: Leaving directory `/dev/shm/tdebase.build'
make[1]: *** [nsplugins/viewer/CMakeFiles/nspluginviewer.dir/all] Error 2
make[1]: Leaving directory `/dev/shm/tdebase.build'
make: *** [all] Error 2

/dev/shm/tdebase/nsplugins/viewer/viewer.cpp:252: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
=======================

Slackware 13.0 uses gcc 4.3.3.

Still need to test on 12.2 (gcc 4.2.4).

We can definitely apply the patch for SW_VIDEOOUT_INSERT, though I'd prefer to use some kind of compile-time udev version check to see if the FIXME items can be enabled or not.

Looks like udev 153 is a minimum requirement for R14 then.  I don't see any way around this; I consider it casualty of the sloppy upstream move from HAL to udev (i.e. there was no point in time where both HAL was actively maintained and udev had all the functions needed to replace HAL).

The compilation failures you posted will need to be fixed.

Temporary tdebase work-around: -DBUILD_NSPLUGINS=OFF.

3.5.12 built on 12.2 so something since then changed in the structures that the older gcc does not like.

>We can definitely apply the patch for SW_VIDEOOUT_INSERT, though I'd prefer to
>use some kind of compile-time udev version check to see if the FIXME items can
>be enabled or not.
You know best how to fix that.

>Looks like udev 153 is a minimum requirement for R14 then.
I don't know whether that is the minimum version. I selected 153 only because I had a copy of those sources on my hard drive (from the Slackware 13.1 tree). Regardless, we should have a udev version sanity check in the configuration process. If you add the sanity check I'll determine the actual minimum udev version that supports udev_monitor_filter_add_match_subsystem_devtype. Somewhere between 141 and 153, so I should not have to bisect too much. :-)

Second thought, the sanity check should happen as soon as possible so people don't waste their time. TQt3 is the first package built.... Looks messy.

Murphy's Law: Slackware 13.0 comes with udev-141. The first version with udev_monitor_filter_add_match_subsystem_devtype is udev-142. IOW, udev-142 would be the minimum version to support R14.

Created attachment 1683 [details]
Fix tdebase FTBFS on older GCC versions

Try the attached patch for tdebase to see if it fixes your build failure.

This is beyond me. The latest R14 FTBFS in 12.2:

/dev/shm/tdelibs/tderandr/libtderandr.cc:1347: error: 'XRRGetOutputPrimary' was not declared in this scope

Slackware 12.2 has Xorg 1.4.2. In that version, Xrandr.h does not contain XRRGetOutputPrimary.

The primary point of this bug report was proving Trinity is not part of the problem in bug 1583 (swapped mouse buttons). I also can't get 3.5.13.x to build on 12.2. So I'm dead in the water.

As I reported in bug 1583, when a remote system runs vncserver from TightVNC, then Trinity krdc has no mouse button problems. I only see the swapped buttons with TDE and KDE4. I'm led to believe I've stumbled into a strange corner case in the basic krfb engine that both desktops inherited from KDE3.

I've beat myself hard the past several days trying to establish a knowable baseline. I can't establish that baseline. The closest I got was 3.5.12 on Slackware 12.2 but 3.5.12 was still very much KDE3 without the many changes introduced in the 3.5.13 and R14 branches. Thus 3.5.12 did not prove anything.

Closing as WONTFIX.

OK, thanks for trying anyway!

Comment on attachment 1683 [details]
Fix tdebase FTBFS on older GCC versions

Pushed to GIT in hash c1dcc6c.