[PyKDE] Supported architectures?

[Ulrich Berning]

Phil Thompson schrieb:

>>Hi,
>>
>>I'm the current maintainer of the pyKDE, pyQt and sip ports (*) for
>>FreeBSD. I
>>recently updated the port to allow it to build for KDE > 3.3.0 (I stuck to
>>the stable realeased tarball and just had the port's Makefile rename the
>>few
>>diff files and such where needed).
>>
>>FreeBSD has the Tier 1 archs of i386, Sparc64, AMD64, and PC98 and the
>>Tier 2
>>archs of Alpha, PowerPC and ia64. These are the platforms for which build
>>clusters are used, also for ports and resulting packages. Periodically
>>(one
>>sooner than the other) packages are built on all these archs and problem
>>reports sent to port maintainers. Recently I was informed by our
>>"pointyhat"
>>build system that it didn't compile on alpha. The good news is that AFAICT
>>on
>>the build cluster i386, ia64, amd64, and sparc64 are OK. Of course I only
>>have i386 here :)
>>
>>So I was wondering, are there any archs other than i386 formally
>>supported? I
>>noticed that for alpha and many others no Linux distribution provides any
>>binary packages. I noticed that Gentoo supports ppc and x86 (which is I
>>guess
>>also ia64 and amd64?).
>>    
>>
>
>Strictly speaking, no platform is *formally* supported. My own development
>environments are amd64, i386 and Windows XP. Ulli Berning does a fantastic
>job of making sure PyQt builds on HP-UX and AIX, so I have high confidence
>in those platforms. I also have confidence in MacOS/X because there are
>enough people using it who would say if there were problems.
>
>  
>
>>FYI, below is the build error I got sent. It looks to me because of
>>differing
>>size of some C types on that platform or something alike. Anyway, I can
>>set
>>the FreeBSD port marked broken ("Does not compile on <arch>" or so) for
>>unsupported archs, so would it be a good idea to do so at least for alpha
>>(some other archs might be reported broken at a later time, as they are
>>not
>>built for so frequently)?
>>
>>Error msg building the port on alpha:
>>.....
>>c++ -c -Wno-deprecated-declarations -pipe -fPIC -O -pipe -mcpu=ev4 -mieee
>>-Wall -W -D_THREAD_SAFE -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I.
>>-I../extra/kde332 -I/usr/local/include -I/usr/local/include/python2.4
>>-I/usr/X11R6/include -o moc_sipkdecorepart0.o moc_sipkdecorepart0.cpp
>>c++ -shared -pthread -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/X11R6/lib
>>-o
>>kdecore.so sipkdecorepart0.o moc_sipkdecorepart0.o -L/usr/local/lib
>>-L/usr/X11R6/lib -lkdecore -lqt-mt -lXext -lX11 -lm
>>/usr/libexec/elf/ld: sipkdecorepart0.o: .got subsegment exceeds 64K (size
>>67720)
>>/usr/libexec/elf/ld: failed to set dynamic section sizes: File format not
>>recognized
>>*** Error code 1
>>
>>Stop in /tmp/a/ports/x11-toolkits/py-kde/work/PyKDE-3.11.3/kdecore.
>>*** Error code 1
>>    
>>
>
>There is probably a linker flag that needs to be passed to increase the
>size of a table. AIX has similar issues and the build system include
>special handling for it. If you can work out what's needed then I'm happy
>to add it to the build system.
>
>Phil
>	
>
I'm afraid, there is no such linker flag for the gnu linker. The only 
thing that might help is to create a linker script that marks the module 
init function as global and all other symbol as local.

Try the following:

Create a file 'kdecore.exp' in the directory where kdecore is built. The 
file should contain the following line '{ global: initkdecore; local: *; 
};' . Then add the following flag to the LFLAGS definition in the 
Makefile: '-Wl,--version-script=kdecore.exp'.
If this doesn't help, the object file sipkdecorepart0.o may contain too 
many symbols. As Hans-Peter Jansen suggested, do not concatenate the 
source files (resulting in smaller object files containing less symbols).

Ulli