Same error as in bug 113045, though the compiler version and distro are different here (FWIW).

Thanks Philip.

*** This bug has been marked as a duplicate of 113045 ***

This is *not* a duplicate of bug 113045. The problem was introduced about 3 days ago. The Makefile.am in kdmlib was changed so that it links against libXau.a. It appears not to be possible to link statically against this lib on SUSE X86_64.

http://websvn.kde.org/branches/KDE/3.5/kdebase/kdmlib/Makefile.am?rev=462294&view=log

Ok, sorry. It's not a duplicate.

It's no bug at all. Just make the libXau.so (shared library) version available.

This looks like a libtool bug for me. But it may never be solved (kdeinit), so please install the shared library version.

Where do I get a shared version of libXau.so? Suse does not provide one. Many 
other distros do not provide one, either.

You are basicly saying that that KDE 3.5 will not support Suse 9.3 on X86_64, 
given that there is no libXau.so provided for it.



On Friday 23 September 2005 8:48 pm, Thiago Macieira wrote:
[bugs.kde.org quoted mail]

Cartman: can you explain why kdmlib needs to link to libXau? It's not provided as a shared library in most distros, so kdmlib should never link to it.

*** Bug 113045 has been marked as a duplicate of this bug. ***

It needs libXau because of new GDM support which uses XAuth functions. Maybe we need some ifdefs or maybe I missed something as it doesn't compile for me without linking to libXau. 

Well also note that what reporter says is a 1) Afaik a gcc bug ( needing -fPIC for static libs ) 2) Distro bug ( You need to use -fPIC for amd64) . This bug is very much invalid in my opinion.

No, creating a shared library with dependency on a static one is not acceptable. libtool can cope with it, but we don't want that.

So, unless libXau is distributed in .so, I oppose to making ksmserver use it. I have to rebuild my KDE to verify what the consequences are, but so far I don't see how this could work anywhere at all.

So your proposed solution is to tell Suse users on AMD64 that KDE 3.5 will not 
be compilable without patches to KDE or recompiling X.org from source?


On Saturday 24 September 2005 5:09 am, ismail  donmez wrote:
> ------- Additional Comments From ismail uludag org tr  2005-09-24 12:09
> ------- Well also note that what reporter says is a 1) Afaik a gcc bug (
> needing -fPIC for static libs ) 2) Distro bug ( You need to use -fPIC for
> amd64) . This bug is very much invalid in my opinion.

As I said, I will investigate further. But, yes, that may very well be the proposed solution: recompile libXau with -fPIC.

In fact, can anyone tell me if that works?

But omitting -lXau fixes the compilation problems on my system. kdebase 
compiles just fine without it.


> ------- Additional Comments From thiago kde org  2005-09-25 06:46 -------
> As I said, I will investigate further. But, yes, that may very well be the
> proposed solution: recompile libXau with -fPIC.
>
> In fact, can anyone tell me if that works?

I will investigate this today. Meanwhile you should tell Suse to use -fPIC on amd64 which is a _must_ and not _should_.

Ok I checked this bug and kdmlib/dmctl.cpp has this :

void
DM::GDMAuthenticate()
{

[...]
        Xauth *xau;
[...]
        while ((xau = XauReadAuth( fp ))) {

etc which comes from libXau. So we need to link to libXau.

Problem is in kdmlib though I don't see any problem. Assigning to kdm maintainer Ossi to get his comments on this.

to put it straight: yes, the problem is that x provides a static library Xau, which we are now linking to ksmserver (which is a dynamic library due to the kdeinit magic). on some systems, this plainly does not work.
i've seen this fixed recently in Xorg cvs. i have nothing better to offer than to wait ...

Tested on Ubuntu & Gentoo both provide a libXau.so .

I have just tested and libXau.a is NOT necessary. All Xau* symbols in use by kdmlib are provided by libX11, not libXau:

$ grep -r Xau . | grep -v \\.svn
./dmctl.cpp:#include <X11/Xauth.h>
./dmctl.cpp:    Xauth *xau;
./dmctl.cpp:    if (!(fp = fopen( XauFileName(), "r" )))
./dmctl.cpp:    while ((xau = XauReadAuth( fp ))) {
./dmctl.cpp:                            XauDisposeAuth( xau );
./dmctl.cpp:            XauDisposeAuth( xau );
./Makefile.am:libdmctl_la_LIBADD = $(LIB_KDECORE) -lXau

$ nm -D /usr/X11R6/lib/libX11.so.6 | grep Xau
00041670 T XauDisposeAuth
00041920 T XauFileName
00041760 T XauGetBestAuthByAddr
00041b50 T XauReadAuth

So, cartman: how did you come to the conclusion that libXau was needed? Did you get any compilation errors?

Yes I had undefined referenced to those XAuFoo functions

Can you try and reproduce it? Tell us what symbol it is and which library it is on.

On Tuesday 27 September 2005 13:47, Thiago Macieira wrote:
[bugs.kde.org quoted mail]

Seems to compile just fine on Gentoo :/ . Maybe its a problem with Ubuntu 
Breezy's X.org .

Someone with Breezy has confirmed that some of the symbols kdmlib needs aren't present in libX11.so.

The X.org version they have is X11R6 6.8.2, which is the same I have here.

This looks like an upstream bug. Can anyone else with a distribution that is not Ubunty/Breezy see the link failure without -lXau? (or, in other words, can everyone else compile kdmlib successfully without -lXau) 

well, it works for me without -lXau, obviously. debian unstable here.

i have no idea how to proceed about this report other than resolving it INVALID - get yourself updated X packages.

I agree. The commit should be reversed and a bug should be filed with Ubuntu.

uhm, no, i think carman's commit is perfectly valid. even if the symbols are in libX11, libXau must still be present, as not doing it would break something like 15 years of link-time compatibility.
what is invalid (as far as kde is concerned) is the report itself - in a modern environment, libXau simply has to be a dynamic lib.
otoh, we could just work around it by adding a test whether -lXau is necessary. only if it is, it has to be a .so file.

I'd rather not add another test, if possible.

But why should we link to libXau if every distribution but Ubuntu/Breezy works without it? That's why I asked if other distributoins had the same issue.

have you tested with anything older than xorg 6.8?

Yes:

System 1 (Conectiva 10):
$ nm -D libX11.so.6 | grep Xau
0003f4f0 T XauDisposeAuth
0003f7c0 T XauFileName
0003f5e0 T XauGetBestAuthByAddr
0003f9e0 T XauReadAuth
$ rpm -qf libX11.so.6
xfree86-libs-common-4.4.0-61875cl

System 2 (Conectiva 9):
$ nm -D libX11.so.6 | grep Xau
0003ef70 T XauDisposeAuth
0003f200 T XauFileName
0003f060 T XauGetBestAuthByAddr
0003f410 T XauReadAuth
$ rpm -qf libX11.so.6
XFree86-libs-common-4.3.0-28971cl

hmm, interesting. can you track this down to when it was introduced? in particular, whether the proprietary unixes also have it?

This must be because Ubuntu switched to modularized X.org which must have cut down on shared symbols. Also libXau.so should be there so I suggest reporting bug to Suse too.

I don't think it was ever introduced. My system and Ubuntu/Breezy are both using X.org 6.8.2.

I can think of two explanations:

1) X.org moves those symbols to libXau.so if libXau.so is built (as opposed to just libXau.a) using a configure option

2) Ubuntu moved those symbols on their own by patching the X.org source code

If it's option #1, we should add a configure test and link if necessary. If it's option #2, Ubuntu should get a bug report and fix it.

i don't think the Xau symbols were in libX11 since ever ... why would libXau exist in the first place then?

Well, for other symbols.

However, note that all symbols found in libX11 are duplicated there:
$ nm /usr/X11R6/lib/libXau.a | grep T\ Xau
00000000 T XauDisposeAuth
00000000 T XauFileName
00000040 T XauGetAuthByAddr
00000040 T XauGetBestAuthByAddr
00000000 T XauLockAuth
00000140 T XauReadAuth
00000000 T XauUnlockAuth
000000d0 T XauWriteAuth

I don't think they ended up in libX11 by accident. It must be intentional, because if libX11 linked to libXau, there would be an indirect dependency in Ubuntu and cartman would never have committed his fix.

So, this boils down to what the X developers' intentions were. And I don't feel like digging through their source code -- writing a configure test is easier.

Created attachment 12960 [details]
Add libXau configure check to kdmlib

Ossi: ksmserver doesn't build due to kdmlib (libdmctl). Should I reassign to
ksmserver, or is kdmlib yours?

Anyways, this patch adds a configure-time check for the Xau* functions libdmctl
uses and determines whether they are in libX11 or libXau. However, it does not
detect whether libXau is required but only libXau.a is provided -- it will show
just a warning then.

Could the people having problem with this issue test the patch? It works for me
here.

Created attachment 12959 [details]
Add libXau configure check to kdmlib

Ossi: ksmserver doesn't build due to kdmlib (libdmctl). Should I reassign to
ksmserver, or is kdmlib yours?

Anyways, this patch adds a configure-time check for the Xau* functions libdmctl
uses and determines whether they are in libX11 or libXau. However, it does not
detect whether libXau is required but only libXau.a is provided -- it will show
just a warning then.

Could the people having problem with this issue test the patch? It works for me
here.

Created attachment 12961 [details]
Add libXau configure check to kdmlib

Ossi: ksmserver doesn't build due to kdmlib (libdmctl). Should I reassign to
ksmserver, or is kdmlib yours?

Anyways, this patch adds a configure-time check for the Xau* functions libdmctl
uses and determines whether they are in libX11 or libXau. However, it does not
detect whether libXau is required but only libXau.a is provided -- it will show
just a warning then.

Could the people having problem with this issue test the patch? It works for me
here.

KDE 3.5.0 has been tagged and no one tested my patch.

SVN version of 3.5 branch has compiled on my system for a while (the Suse 9.3 AMD64 that had problems with -fPIC and libXau). So I do not think it is a problem on this distro.

finally getting rid of it. i just assume all distros are fixed by this time.