Bug 2850

htmlattrs.cpp.o is not built. Some other things like htmltags.cpp.o are also not built.

Even if all dependencies (arts, dbus-tqt, etc.) are from GIT,
the build fails:

Scanning dependencies of target tdehtml-shared
[ 87%] Building CXX object tdehtml/CMakeFiles/tdehtml-shared.dir/tdehtmlview.cpp.o
[ 87%] Building CXX object tdehtml/CMakeFiles/tdehtml-shared.dir/tdehtml_part.cpp.o
[ 87%] Building CXX object tdehtml/CMakeFiles/tdehtml-shared.dir/tdehtml_run.cpp.o
[ 87%] Building CXX object tdehtml/CMakeFiles/tdehtml-shared.dir/tdehtml_factory.cpp.o
[ 87%] Building CXX object tdehtml/CMakeFiles/tdehtml-shared.dir/tdehtml_settings.cc.o
[ 87%] Building CXX object tdehtml/CMakeFiles/tdehtml-shared.dir/tdehtml_events.cpp.o
[ 87%] Building CXX object tdehtml/CMakeFiles/tdehtml-shared.dir/tdehtml_ext.cpp.o
[ 89%] Building CXX object tdehtml/CMakeFiles/tdehtml-shared.dir/tdehtml_pagecache.cpp.o
[ 89%] Building CXX object tdehtml/CMakeFiles/tdehtml-shared.dir/tdehtml_iface.cc.o
[ 89%] Building CXX object tdehtml/CMakeFiles/tdehtml-shared.dir/tdehtml_printsettings.cpp.o
[ 89%] Building CXX object tdehtml/CMakeFiles/tdehtml-shared.dir/tdehtmlimage.cpp.o
[ 89%] Building CXX object tdehtml/CMakeFiles/tdehtml-shared.dir/kjserrordlg.cpp.o
[ 89%] Building CXX object tdehtml/CMakeFiles/tdehtml-shared.dir/htmlpageinfo.cpp.o
[ 89%] Building CXX object tdehtml/CMakeFiles/tdehtml-shared.dir/tdehtml_iface_skel.cpp.o
[ 89%] Linking CXX shared library libtdehtml.so
misc/libtdehtmlmisc.a(htmlhashes.cpp.o): In function `tdehtml::getAttrID(char const*, int)':
htmlhashes.cpp:(.text+0x275): undefined reference to `findAttr(char const*, unsigned int)'
collect2: error: ld returned 1 exit status
make[2]: *** [tdehtml/CMakeFiles/tdehtml-shared.dir/build.make:521: tdehtml/libtdehtml.so.14.0.0] Error 1
make[1]: *** [CMakeFiles/Makefile2:13534: tdehtml/CMakeFiles/tdehtml-shared.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

After reading this:

http://www.slackware.ru/forum/viewtopic.php?f=8&t=1918&sid=507a27f4d301ccc9907f7377eba4214d&start=100

I did this:

sed -i '/__attribute/d' tdelibs-master/tdehtml/misc/htmlattrs.c

and it compiled.

interesting because on debian in 14.1 it compiles

looking for symbol in question

$ nm -C /usr/lib/debug/opt/trinity/lib/libtdehtml.so.14.0.0  | grep getAttrID
000000000035a910 t tdehtml::getAttrID(char const*, int)

I hope this helps

regards

tdelibs builds fine in many deb and rpm distros. Most likely this bug was caused by either inconsistent sources or incorrect building options.
Given that the user is no longer using TDE for quite a while (as state in other bug reports), I am closing the bug as invalid.
If you can still reproduce it, please feel free to reopen it.

Do those rpm and deb systems on which tdelibs build use the newest GCC?

I did post a link to a Russian slackware forum where they explain that the problem is with the new GCC and inlining functions.

You can close this bug if you want to, but it will come back again when someone with a newer system and compiler tries to build tde.

Hi Thomas,
thanks for the feedback on this (I thought you were not using TDE any more... Am I confused with a different user?)

As far as I can say, tdelibs builds fine in all supported Debian/Ubuntu distros, some of which are very old and some are very new (debian buster, ubuntu 18.10 - debian buster uses gcc 8.2 as of today).
As for rpm, I am not sure which version of gcc was used, but I can see tdelibs builds ok on various openSuse version.

__attribute__ is used conditionally in the code:

#ifdef __GNUC_STDC_INLINE__
__attribute__ ((__gnu_inline__))
#endif

so given the evidence above I believe it is a matter of choosing the right defines when compiling.

Anyhow findAttr is the only function in all TDE that is using the __gnu_inline__ attribute, so I guess it makes sense to remove it completely.

Commits 6629107b (R14.1) and a4f7c4bd (R14.0) align the definition of findAttr to the one of hash__attr. This should possibly help with this problem, although it does not seem to show up is most of the other distros.

Thomas, if you wish/want to retest, you are welcome (although I seem to remember you are no longer on TDE).

I think I'll just leave you with these few notes.

I am using KDE 3.5.10. I tried Trinity in hopes that it would have fewer bugs and more features. I found that a lot of the bugs in KDE3 that bothered me were still in Trinity, plus some new ones, like not being able to use some parts of the control panel. (I submitted bug reports.) I was also bothered by the need to patch konqueror to use the newest OpenSSL. In the end, the new features, like dealing with xz archives, did not outweigh the bugs. So I went back to KDE3, patched my kweather app so that it works again, and am reasonably content. I know there are only one or two people working on Trinity, so I understand how long and difficult it is to deal with everything.

All I want is a normal computer desktop, not something that looks like a cell phone or an iPad. Having said all that, I hope that Trinity becomes the desktop that I want. But it's just not ready. I'm sure that I'll try it again some day.

Before I go, let me also just give my opinion about Qt4. I think that moving to Qt4 would be a mistake for two reasons. First, everyone is moving to Qt5 and Qt4 is no longer supported. That means that you will be in a position of having to fix it like you now have to fix Qt3. Imagine all the new bugs that will create. Second, it's a step toward bloat that betrays the whole purpose of a simple desktop environment. If I want bloat, I'll try KDE5.

I'll hope you'll take my comments as coming from a place of positive intentions, rather than just assume that I'm an ass (even if I am one in real life). I honestly do wish you the best with this project.