Bug 43696 – x11/qt fails because of missing ibase.h

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Carsten Lohrke (RETIRED) 2004-03-04 02:22:53 UTC]

Adding the header path should fix the problem. Firebird 1.0 installs to /opt/interbase and firebird 1.5 in /opt/firebird, so both include paths should be added, even though it seems that 1.0 will be dropped as soon as 1.5 is stable (Bug 42518).

A similar problem: Qt's build process autodetects available header files and includes the related db support. This shouldn't happen. I want Qt only to include the db's, which are specified by use flag, so if the flag isn't set, the option -no-sql-<driver> should be added.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

[Comment 1 Carsten Lohrke (RETIRED) 2004-03-04 03:10:15 UTC]

Oh, just found out that my old Firebird 1.0 installation missed the symlinks to /usr/include, so only the second issue is a problem.

[Comment 2 Caleb Tennis (RETIRED) 2004-03-04 04:57:10 UTC]

Qt will autodetect headers, but *shouldn't* explicitly build or include any plugins that aren't called for or added by the command line options.

[Comment 3 Carsten Lohrke (RETIRED) 2004-03-04 05:09:49 UTC]

*sigh* Of course you're right Caleb. 

[Comment 4 Caleb Tennis (RETIRED) 2004-03-04 05:52:09 UTC]

Glad to hear :) - I was getting worried that I had broken something.

[Comment 5 Carsten Lohrke (RETIRED) 2004-03-04 06:27:10 UTC]

One simple question: Why does the -no-sql-<driver> option exist then? Don't know much about autoconf/make, but I don't think there's always a complementary option!?

[Comment 6 Caleb Tennis (RETIRED) 2004-03-04 06:32:39 UTC]

the configure script for Qt is a custom written one by Trolltech, it's not automake or autoconf based.

Not exactly sure, but I think it has something to do with saved options in a cache.  I think if you configure stuff on, then later rerun "configure" it will reload the saved options unless you explicitly turn them off/on.

[Comment 7 Carsten Lohrke (RETIRED) 2004-03-04 07:21:56 UTC]

Hm - that means this can affect portage when having noclean in features and changing use flags between two compilations.

When I had problems with compiling Qt (like today), I have always to rm -rf /var/tmp/portage/qt* before compiling again, otherwise the compilation will fail for other reasons. I don't think this has something to do with it, but there are so much users having problems with compiling Qt/kde* ebuilds lately. Maybe it would be good to be more explicit. For me, the last qt/kde ebuilds, which compiled out of the box, where 3.1.* ones.

[Comment 8 Caleb Tennis (RETIRED) 2004-03-04 07:28:39 UTC]

ok, I'll take a look at it when I get home tonight.