Bug 1311

Created attachment 964 [details]
CMakeFiles/CMakeError.log

Created attachment 965 [details]
CMakeFiles/CMakeOutput.log

Is this a Trinity build problem?

Please check upstream with your distro for a patched version of fribidi. For certain, recent versions of fribidi are required to be patched.

I'm building Trinity packages in Slackware 14.0, which uses fribidi 0.19.2. The Slackware fribidi package is patched against the exact type of failure described. For certain, recent versions of fribidi are required to be patched. You can view the patch here:

http://slackware.osuosl.org/slackware-14.0/source/l/fribidi/

Refer to bug report 1063 for examples of how Trinity packages were patched, which is the same type of patching that is required for fribidi. Although tdegraphics might have slipped through scrutiny in bug report 1063, I believe the problem is fribidi and not Trinity.

(In reply to comment #3)
> Is this a Trinity build problem?
> 
yes, it seems to be a trinity problem.
I'm not sure why it doesn't affect you... 
May be you got /usr/include/glib-2.0/ in your INCLUDE_PATH for some reason?

> Please check upstream with your distro for a patched version of fribidi. For
> certain, recent versions of fribidi are required to be patched.
> 
> I'm building Trinity packages in Slackware 14.0, which uses fribidi 0.19.2. The
> Slackware fribidi package is patched against the exact type of failure
> described. For certain, recent versions of fribidi are required to be patched.
> You can view the patch here:
> 
> http://slackware.osuosl.org/slackware-14.0/source/l/fribidi/
> 
yep... we got the same patch: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/fribidi/

> Refer to bug report 1063 for examples of how Trinity packages were patched,
> which is the same type of patching that is required for fribidi. Although
> tdegraphics might have slipped through scrutiny in bug report 1063, I believe
> the problem is fribidi and not Trinity.

nope they are different... there described that compilation fails due to it tries to include old-style glib headers. But here it can't find glib.h (the new one) in time of cmake configuration, so cmake doesn't sets corresponding variable.

(In reply to comment #4)
> (In reply to comment #3)
> > Is this a Trinity build problem?
> > 
> yes, it seems to be a trinity problem.
> I'm not sure why it doesn't affect you... 
> May be you got /usr/include/glib-2.0/ in your INCLUDE_PATH for some reason?
> 

Or you could compile fribidi without glib. It isn't strictly pointed in the slackbuild if it compiles --with-glib or --without-glib. So it should default to auto.

for check you can do:

alexander@goblin /tmp $ grep -r FRIBIDI_USE_GLIB /usr/include/fribidi/fribidi-
config.h
#define FRIBIDI_USE_GLIB 1

You're correct: the Slackware build script does not identify whether glib is used. fribidi-config.h shows:

#define FRIBIDI_USE_GLIB 0

which implies the Slackware version of fribidi is built without glib support. That must be the default.

I'll have to build my own fribidi package with an explicit --with-glib, verify fribidi-config.h contains #define FRIBIDI_USE_GLIB 1, and then build tdegraphics.

What version of fribidi are you using?

I ran a quick test of building fribidi. When not explicitly declaring --with-glib=yes, the configure process defaults to --with-glib=auto, which results in fribidi-config.h: #define FRIBIDI_USE_GLIB 0. When explicitly declaring --with-glib=yes then fribidi-config.h: #define FRIBIDI_USE_GLIB 1.

I still have to build tdegraphics and confirm the build failure.

This bug was discovered in May 2011. Somewhere in the various fribidi updates, the header file fribidi_types.h was renamed to fribidi-types.h. Commits 9e542b76 2011-05-06 and 65627278 2010-09-10 updated the associated files to look for both spellings.

The build failure on my Slackware 14.0 64-bit build system:

/dev/shmtdegraphicsksvg/impl/libs/libtext2path/src/Converter.cpp:32:35: fatal error: fribidi/fribidi_types.h: No such file or directory

The cause of the failure is FRIBIDI_NEW_FILENAME is not being correctly defined thereby defaulting to looking for fribidi/fribidi_types.h rather than fribidi/fribidi-types.h. My build output:

-- checking for one of the modules 'fribidi'
-- Looking for fribidi/fribidi-types.h
-- Looking for fribidi/fribidi-types.h - not found
...
//Have include fribidi/fribidi-types.h
FRIBIDI_NEW_FILENAME:INTERNAL=

I tried many ways to get fribidi/fribidi-types.h recognized but to no avail.

Looking at my Slackware 14.0 32-bit build log from many weeks ago:

-- checking for one of the modules 'fribidi'
-- Looking for fribidi/fribidi-types.h
-- Looking for fribidi/fribidi-types.h - found
...
//Have include fribidi/fribidi-types.h
FRIBIDI_NEW_FILENAME:INTERNAL=1

I have only two build systems to compare, but as the problem seems to only occur on the 64-bit system, I suspect some kind of 64-bit anomaly.

Created attachment 968 [details]
patch to fix the problem

> I have only two build systems to compare, but as the problem seems to only
> occur on the 64-bit system, I suspect some kind of 64-bit anomaly.
I haven't tested that on x86 but it should fail there as well...
There is nothing special it this... It's just a trivial CMake mistake.

Created attachment 969 [details]
patch to fix the problem

The patch seems to resolve the problem on Slackware 14.0 64-bit. I would like Serghei to review the patch before pushing to GIT.

Created attachment 971 [details]
Updated patch

I updated the patch as instructed by Serghei in the dev mail list discussion. Works fine here with Slackware 14.0 64-bit.

Please test. :)

Fixed in GIT hash f0e6b090