Comment 1 Ceri Davies 2004-02-24 21:28:28 UTC

Responsible Changed
From-To: gnats-admin->freebsd-ports-bugs

Reassign misfiled PR.

As sent to author me AT davidsansome.com:
----------------------------------------------------------

Against the 0.3 source download. I don't know if you have a FreeBSD box at 
your hands but the PR is at 

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/63282

The patches can be derived from there or once/if the port gets comitted or 
from me if you like.

It seems to work OK on FreeBSD-5.2-RELEASE and 5.2-CURRENT, I don't have 
many GTK apps installed as I use maily KDE; tried it on gimp-1.3 and that 
worked and tried on a wx-python/wx-gtk2 app of my own (the "OK" button looks 
weird or has no image/text at all, most widgets seem OK, some, like 
textfields lack the frame border when looked at with one of the Plastik 
themes). Gimp may hang, but I doubt it's because of the engine (FreeBSD 
recently changed pthread libs and I think that's the cause here).  Of course 
it requires some testing on other FreeBSD versions to see if it works at all 
there.

It was a simple port. I submitted it to ports@freebsd without requesting 
maintainership myself. This is better off with the overall KDE or Gnome 
port/package team IMHO. If it gets into the tree I'm sure people will try it 
and complain if it doesn't work. 

Thanks for your software! Would appreciate a headsup if the major version 
changes. I'll be happy to provide more feedback if you desire so.

Best regards,

Dan


This text also sent to freebsd-gnats-submit@FreeBSD.org as follow-up to 
ports/63282

Comment 3 Tilman Keskinoz 2004-03-18 17:43:11 UTC

State Changed
From-To: open->feedback

Does not build on STABLE: 

gcc -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -I. -I. -I/usr/local/include/atk-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/X11R6/include/gtk-2.0 -I/usr/X11R6/lib/gtk-2.0/include -I/usr/X11R6/include/pango-1.0 -I/usr/X11R6/include -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/X11R6/include/ -I/usr/local/include -I/usr/X11R6/include -I/usr/X11R6/include -D_GETOPT_H -O -pipe -march=k6 -Wp,-MD,.deps/qt_theme_draw.pp -c qt_theme_draw.c        -fPIC -DPIC -o qt_theme_draw.lo 
qt_theme_draw.c: In function `draw_shadow': 
qt_theme_draw.c:302: syntax error before `*' 
qt_theme_draw.c:323: `gc1' undeclared (first use in this function) 
qt_theme_draw.c:323: (Each undeclared identifier is reported only once 
qt_theme_draw.c:323: for each function it appears in.) 
qt_theme_draw.c:323: `gc2' undeclared (first use in this function)

This message is also Re: [ACKNOWLEDGE AUTHOR] Submitted a FreeBSD port for 
gtk-qt-engine

On Saturday 20 March 2004 19:29, you wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Danny,
>
> Sorry for the late reply, I've been away this month :(
>
> I'm not familiar with the BSD ports system, or how things are submitted.
> Thanks for doing it for me ;)

OK, let me explain. There are port submitters who send in the makefile with 
patches and anything needed to make the source code compile and install on 
FreeBSD. Things like install prefix and compiler options can be specified. 
The ports system first fetches the source code, first default preference is 
from the authors website or FTP repository, then it checks md5 sum, then 
extracts (bzip2, gzip, zip) source into a "work" directory. Then applies 
patches, then configures (usually this step isn't specified) if any, then 
builds, and installs and finally registers and optionally packs the result 
into a binary package. 

So a port maintainer or submitter mainly changes paths and stuff and other 
small patches. Well, sometimes big ones. It works a lot like Gentoo Linux' 
ebuilds which was inspired by *BSD ports. To browse ports please look at 
http://www.freebsd.org/ports/index.html or http://www.freshports.org 

> What happens now?  Should I notify anyone when there is a new version?

Only port committers have CVS access. I don't. I recently recieved a reply 
from the GNATS database that the port doesn't compile on FreeBSD-STABLE 
(that's 4.9 at the time). I'm running 5.x (called -CURRENT) and the next 
release 5.3 is slated to become the -STABLE branch. 

So I'm kinda stuck and wondering if the problem was caused by other ports 
(gtk) rather than it being a build problem with this software. 

I've rebuilt gtk20 and gtk-qt-engine without any problems, including the 
latest font changes. I have tried building the port against gcc2.95, 3.2 and 
3.3 (the default in 5.x, I don't know about 4.x, might be 2.95 still) and all 
worked fine. I also tried with gtk built with and without what's called the 
"experimental menu dropshadow patch". In both cases gtk-qt-engine worked fine 
on my 5.2-CURRENT desktop. 

I will send this as feedback to the FreeBSD bug database also, this entry is 
at http://www.freebsd.org/cgi/query-pr.cgi?pr=63282 please look there also 
for the reported build error, perhaps it rings a bell (disclaimer: I'm not a 
C programmer).

I hope someone can provide more feedback, otherwise I'll just resubmit when we 
arrive at FreeBSD-5.3. I took the liberty of CC'ing to ports@. This port is 
really an asset to KDE but I don't have spare boxen to run -STABLE on.

> > Thanks for your software! Would appreciate a headsup if the major version
> > changes. I'll be happy to provide more feedback if you desire so.
>
> Will do :)

In the port's Makefile I have set maintainer to be ports@freebsd.org (that is: 
nobody). Not because I'd hate to be it, but rather because if this is adopted 
it should probably be in the hands of our kde@ team I think. But I'll happily 
submit any version bumps. 

Finally some random layman's (OK, that's a bit of an understatement) 
observations: Textfields and combo's and the like have no border. Toolbars 
have no border. Scrollbars leave an open "non-scrollable" space at the bottom 
or at the right. Standard OK and Cancel buttons should have no image and 
scale normally not bigger (observed in gimp-2-pre). In the Dir menu the OK 
button, when used in an app without icon, shows no text and after selection 
of the dir it becomes a flattened rectangle altogether (observed in an wx-gtk 
app of my own). Hope this helps! I looked at them using the PlastiK theme.

All in all, gtk apps look a LOT better this way when one runs a KDE system. 
Haven't observed any apparent crashes, hangs, panics or memory sinks.

> David Sansome
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFAXI2MBxzHzN8T1fgRAgOWAJ971B3CFmjj0YMNRI1OB9VWBsrYwwCfekrw
> g/EVSLt9BnNl6Lfy7SfW8QU=
> =4Gyk
> -----END PGP SIGNATURE-----


Greetings,

Dan

On Thursday 18 March 2004 18:43, you wrote:
> Synopsis: [NEW PORT] x11-toolkits/gtk-qt-engine
>
> State-Changed-From-To: open->feedback
> State-Changed-By: arved
> State-Changed-When: Thu Mar 18 09:43:11 PST 2004
> State-Changed-Why:
> Does not build on STABLE:
>
> gcc -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -I. -I. -I/usr/local/include/atk-1.0
> -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
> -I/usr/X11R6/include/gtk-2.0 -I/usr/X11R6/lib/gtk-2.0/include
> -I/usr/X11R6/include/pango-1.0 -I/usr/X11R6/include
> -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/X11R6/include/
> -I/usr/local/include -I/usr/X11R6/include -I/usr/X11R6/include -D_GETOPT_H
> -O -pipe -march=k6 -Wp,-MD,.deps/qt_theme_draw.pp -c qt_theme_draw.c       
> -fPIC -DPIC -o qt_theme_draw.lo qt_theme_draw.c: In function `draw_shadow':
> qt_theme_draw.c:302: syntax error before `*'
> qt_theme_draw.c:323: `gc1' undeclared (first use in this function)
> qt_theme_draw.c:323: (Each undeclared identifier is reported only once
> qt_theme_draw.c:323: for each function it appears in.)
> qt_theme_draw.c:323: `gc2' undeclared (first use in this function)
>
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=63282

Author David Sansome <me AT davidsansome.com> suggested that the build error 
might be caused by gdk not being included "whereas it is probably included by 
default in your version of GTK". 

It shouldn't make any difference if it's on -CURRENT or -STABLE anyway because 
ports are always a HEAD. I tested with and without the patch below 
pkg_deinstall'ing gtk and then have it be pulled in and built via this port. 
No probs.

I'm thinking that this may have been a temporary problem with the gtk port. 
Could someone test this on -STABLE, both with and without the below patch 
which explicitly includes gdk? I don't have a spare box to test with -STABLE.

workstation# cat files/patch-qt_theme_draw.c
--- qt_theme_draw.c.orig        Mon Feb  9 19:50:12 2004
+++ qt_theme_draw.c     Tue Mar 30 02:09:08 2004
@@ -1,5 +1,6 @@
 #include <math.h>
 #include <string.h>
+#include <gdk/gdk.h>
 #include <gtk/gtkprogressbar.h>
 #include <gtk/gtkrange.h>
 #include <gtk/gtknotebook.h>

Dan

(CC'd to arved and David; also gnats ports/63282 -- Hope I didn't over-CC)

Comment 6 Tilman Keskinoz 2004-04-15 18:04:32 UTC

State Changed
From-To: feedback->open

feedback arrived

Comment 7 Thierry Thomas 2004-05-30 23:17:29 UTC

State Changed
From-To: open->closed


New port added, thanks! 
(with some quirks)

Comment 8 Michael Nottebrock 2004-05-31 02:45:34 UTC

Danny: There's no way this port could have ever compiled with gcc295, not in 
FreeBSD 5.x or elsewhere. I have hacked it into compiling by moving the 
failing declarations, since you already contacted the author before, you 
might want to forward files/patch-qt_theme_draw.c to him for reference (the 
additional include is not necessary).

Thierry: Don't use USE_GCC=3.x for anything which links against anything C++. 
gcc 2.x and gcc 3.x have incompatible ABI for binaries compiled from C++ code 
and since this engine links against Qt, this port was effectivly committed 
broken on -STABLE (but should be fixed now).

On Tuesday 01 June 2004 02:05, Danny Pansters wrote:

> Michael, I tried again with gcc-2.95 from ports on 5.2-something. Here's
> the result:
>
> Workstation# make deinstall
> ===>  Deinstalling for x11-toolkits/gtk-qt-engine
> ===>   Deinstalling gtk-qt-engine-0.3
> workstation# cat Makefile | grep GCC
> USE_GCC=        2.95

[...]

> gcc -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -I. -I. -I/usr/local/include/atk-1.0

For some reason, the USE_GCC has no effect for you. The ports version of gcc 
2.95 installs gcc295 and g++295, and those should be used here. Try make 
CC=gcc295 CXX=295. I assure you again: The source as distributed is NOT 
compileable with gcc 2.95. It only is with the patches in 
files/patch-qt_theme_draw.c.

> Note that qt_theme_draw only gives warnings. Could run gimp-2 fine with my
> KDE theme on it. Anyway this bug should be reopened not closed (and not
> accepted) if it doesn't work OK. It really builds and runs here though.

It's fixed in ports for now, this PR does not need reopening. You should 
however forward the necessary patches to the author if possible.

> I'll be the first to admid that I'm not much into the guts of GTK but I'm
> wondering if the problems observed aren't gtk things solely
> [...]

No. It's a gcc issue, gcc 2.95's parser just isn't as relaxed about 
declarations as gcc 3.x's.

-- 
   ,_,   | Michael Nottebrock               | lofi@freebsd.org
 (/^ ^\) | FreeBSD - The Power to Serve     | http://www.freebsd.org
   \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org

Comment 10 Michael Nottebrock 2004-06-01 02:33:21 UTC

On Tuesday 01 June 2004 03:08, Danny Pansters wrote:

> Thanks very much for your speedy reply. That would be a ports bug then, no?

It seems something in your environment prevents CC/CXX from being used. Or 
perhaps you override them in /etc/make.conf?

> workstation# make CC=gcc295 CXX=295 install clean

That was a typo of mine, it should be CXX=g++295 of course.

> checking whether the C compiler (gcc -O -pipe  ) works... yes
> checking whether the C compiler (gcc -O -pipe  ) is a cross-compiler... no
> checking whether we are using GNU C... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking for c++... (cached) c++
> checking whether the C++ compiler (c++ -O -pipe ) works... yes
> checking whether the C++ compiler (c++ -O -pipe ) is a cross-compiler... no

[...]

> gcc -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -I. -I. -I/usr/local/include/atk-1.0

[...]

> c++ -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -I. -I. -I/usr/local/include/atk-1.0

[...]

As you can see, neither the CC nor the CXX you set are being used. You should 
see the changed compiler already in the configure script, like this:

[lofi@lofi]:0:/usr/ports/x11-toolkits/gtk-qt-engine # make CC=gcc295 
CXX=g++295
===>  Extracting for gtk-qt-engine-0.3
>> Checksum OK for gtk-qt-engine-0.3.tar.bz2.
===>  Patching for gtk-qt-engine-0.3
===>  Applying FreeBSD patches for gtk-qt-engine-0.3
===>   gtk-qt-engine-0.3 depends on file: /usr/X11R6/bin/moc - found
===>   gtk-qt-engine-0.3 depends on executable: gmake - found
===>   gtk-qt-engine-0.3 depends on file: /usr/local/libexec/libtool13/libtool 
- found
===>   gtk-qt-engine-0.3 depends on executable: pkg-config - found
===>   gtk-qt-engine-0.3 depends on file: /usr/local/bin/intltool-extract - 
found
===>   gtk-qt-engine-0.3 depends on shared library: X11.6 - found
===>   gtk-qt-engine-0.3 depends on shared library: glib-2.0.400 - found
===>   gtk-qt-engine-0.3 depends on shared library: atk-1.0.600 - found
===>   gtk-qt-engine-0.3 depends on shared library: pango-1.0.399 - found
===>   gtk-qt-engine-0.3 depends on shared library: gtk-x11-2.0.400 - found
===>  Configuring for gtk-qt-engine-0.3
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c -o root -g wheel
checking whether build environment is sane... yes
checking whether gmake sets ${MAKE}... yes
checking for working aclocal-1.4... missing
checking for working autoconf... found
checking for working automake-1.4... missing
checking for working autoheader... found
checking for working makeinfo... found
checking whether to enable maintainer-specific portions of Makefiles... no
checking host system type... i386-unknown-freebsd5.2.1
checking for gcc... gcc295
checking whether the C compiler (gcc295 -O -pipe -mcpu=pentiumpro ) works... 
yes
checking whether the C compiler (gcc295 -O -pipe -mcpu=pentiumpro ) is a 
cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc295 accepts -g... yes
checking for c++... g++295
checking whether the C++ compiler (g++295 -O -pipe -mcpu=pentiumpro ) works... 
yes
checking whether the C++ compiler (g++295 -O -pipe -mcpu=pentiumpro ) is a 
cross-compiler... no


> > It's fixed in ports for now, this PR does not need reopening. You should
> > however forward the necessary patches to the author if possible.
>
> Perhaps the author can make out any nescessary patches. From what info I
> can gather, I can't. I will forward this message like I did the last one as
> you might have noticed though.

Ugh, I didn't. However, the patches are in 
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/x11-toolkits/gtk-qt-engine/files/patch-qt_theme_draw.c?rev=1.2&content-type=text/plain

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Ugh, I didn't. However, the patches are in
> http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/x11-toolkits/gtk-q=
t-
>engine/files/patch-qt_theme_draw.c?rev=3D1.2&content-type=3Dtext/plain

Danny, Michael,

Thanks for the work you've done on this - I've applied the patch to=20
freedesktop.org CVS.

So is this all working correctly now, or is there anything else I need to d=
o?

Thanks,
David Sansome
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAvLdfBxzHzN8T1fgRAhsMAJ9OIaGn3+vSwF0uXdLRYkxHYXPjlACgl1De
/gXSWSre88nNvJeB0gPGvYo=3D
=3Dw3ni
=2D----END PGP SIGNATURE-----