Bug 486045 - graphviz php extension fails to build because of "swig --help" format change
graphviz php extension fails to build because of "swig --help" format change
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: graphviz (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Patrick Laughton
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-17 19:49 EST by John Ellson
Modified: 2009-03-02 22:00 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-02 22:00:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for "configure.ac" - should be adptable to "configure" script (1.09 KB, patch)
2009-02-17 19:49 EST, John Ellson
no flags Details | Diff
patch to graphviz-spec (1.08 KB, patch)
2009-02-25 14:08 EST, John Ellson
no flags Details | Diff
patch to configure (637 bytes, patch)
2009-02-25 14:09 EST, John Ellson
no flags Details | Diff
patch to tclpkg/gv/gv.i (1.32 KB, patch)
2009-02-25 14:10 EST, John Ellson
no flags Details | Diff

  None (edit)
Description John Ellson 2009-02-17 19:49:33 EST
Created attachment 332318 [details]
patch for "configure.ac" - should be adptable to "configure" script

Description of problem:
graphviz will fail to rebuild at the moment because of a recent update to swig which changed the format of "swig --help".
I've attached the change that I made upsteam to deal with this.

Version-Release number of selected component (if applicable):
graphviz-2.20.3-1.fc11.2
swig-1.3.38-2.fc11

How reproducible:
100%

Steps to Reproduce:
1.attempt to rebuild with swig-1.3.38-2
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 John Ellson 2009-02-25 14:04:26 EST
There was another problem resulting from the swig update too.   Following are patches to fix the graphviz mass-rebuild failure.
Comment 2 John Ellson 2009-02-25 14:08:10 EST
Created attachment 333206 [details]
patch to graphviz-spec
Comment 3 John Ellson 2009-02-25 14:09:10 EST
Created attachment 333207 [details]
patch to configure
Comment 4 John Ellson 2009-02-25 14:10:01 EST
Created attachment 333208 [details]
patch to tclpkg/gv/gv.i
Comment 5 John Ellson 2009-02-27 13:11:26 EST
Spot,

Re: http://koji.fedoraproject.org/koji/buildinfo?buildID=91601

It seems that the BR for java-devel no longer pulls in the provider of jni.h ?


jni.h on my system is /usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/include/jni.h
which is from:  java-1.5.0-gcj-devel-1.5.0.0-25.fc11.x86_64


How should the BR be written?
Comment 6 Tom "spot" Callaway 2009-02-27 14:17:25 EST
I don't think this is accurate. 

[spot@velociraptor devel]$ rpm -qlp java-1.6.0-openjdk-devel-1.6.0.0-13.b14.fc11.i586.rpm |grep jni
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/include/jni.h
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/include/linux/jni_md.h
Comment 7 Tom "spot" Callaway 2009-02-27 14:18:33 EST
I'm not sure why it can't find it on i586, whereas, it can on x86_64. I tried forcing the includes in the cflags and it still failed...
Comment 8 John Ellson 2009-02-27 14:33:21 EST
configure needs to find jni.h or it will disable the build of the java components

Is possible that there is a problem with "Provides: java-devel" in the java-1.6.0-openjdk-devel.i586 rpm?
Comment 9 Tom "spot" Callaway 2009-02-27 14:36:05 EST
[spot@velociraptor devel]$ rpm -qp java-1.6.0-openjdk-devel-1.6.0.0-13.b14.fc11.i586.rpm --provides |grep java-devel
java-devel = 1:1.6.0
java-devel-openjdk = 1:1.6.0.0

Nope. It's also definitely getting pulled into the buildroot, but it isn't getting found by configure.
Comment 10 John Ellson 2009-02-27 15:14:23 EST
I compiled this test.c:   
    #include <jni.h>
    int main (int argc, char *argv[]) { return 0; }
with:
    gcc test.c -E | grep jni.h
and saw:
    # 1 "/usr/lib/gcc/x86_64-redhat-linux/4.4.0/include/jni.h" 1 3 4 

This jni.h comes from:
    libgcj-devel-4.4.0-0.21.x86_64
but:
    rpm -q --provides libgcj-devel-4.4.0-0.21.x86_64
      libgcj-devel = 4.4.0-0.21
      libgcj-devel(x86-64) = 4.4.0-0.21
doesn't include a provides for java-devel.
Comment 11 Tom "spot" Callaway 2009-02-27 15:21:15 EST
Well, does it build against libgcj or does it build against openjdk?
Comment 12 John Ellson 2009-02-27 16:27:56 EST
There are no special -I flags in the build.  So, on my ststem its apparently picking up jni.h from java-devel.   But I'm just doing an rpmbuild, not a mock build, so the koji environment could be (apparently is) different.

The spec file just does  BR java-devel.   So it will take whatever package decides to provide that, and expects that package to provide a jni.h in the default include path.

How does one set/get the default include path?
Comment 13 John Ellson 2009-02-27 16:29:16 EST
Sorry, I meant to say:
    "... on my system its apparently picking up jni.h from libgcj-devel."
Comment 14 Tom "spot" Callaway 2009-02-27 19:46:32 EST
okay, so I'll just change the BuildRequires to be libgcj-devel. Does the java plugin actually need a java runtime (Requires: java) or can I take that out too and let it be the autodetected Requires: libgcj ?
Comment 15 John Ellson 2009-02-27 20:25:15 EST
Autodetect should be fine
Comment 16 Tom "spot" Callaway 2009-03-02 10:39:09 EST
Okay, so I've done some more debugging here. The issue is this:

The configure script is checking for a functional "java" command, which libgcj doesn't really provide. After giving this some more thought, we really do want to use the openjdk packages here.

Through trial and error, I found that we need these includes to use jni.h:

-I%{java_home}/include/ -I%{java_home}/include/linux/ (where %{java_home} is /usr/lib/jvm/java/ on i586).

The configure script has a JAVA_INCLUDES variable that seems like it would work, but as is, it only gets used on OSX (darwin) and for all other platforms, gets unset (even if it is passed on the configure invocation). I can hack it in for Fedora (and I probably will do this to get it building), but that's not the proper upstream solution.
Comment 17 John Ellson 2009-03-02 19:19:06 EST
> The configure script has a JAVA_INCLUDES variable that seems like it would
work, but as is, it only gets used on OSX (darwin) and for all other platforms,
gets unset

and this works on rhel5,fedora5,6,7,8,9,10,   i386 and x86_64

Its a regression that this no longer works on fc11, and it only happened in the last 2 or 3 weeks.
Comment 18 Tom "spot" Callaway 2009-03-02 19:24:33 EST
What works? Overriding JAVA_INCLUDES? I can't see any possible way it would work, as the configure script overrides it to null unless the os is Darwin.

Perhaps the autodetection of the java headers worked in previous releases, I'm not sure why it suddenly stopped in rawhide.
Comment 19 John Ellson 2009-03-02 19:33:15 EST
Having an empty JAVA_INCLUDES has worked for years.   Somehow jni.h is found
in the default include path.

Actually, its only broken in koji.  Building with rpmbuild still works fine.
Comment 20 John Ellson 2009-03-02 19:40:41 EST
try compiling jni.c:
    #include <jni.h>
    int main (int argc, char *argv[]) {return 0;}

with:
    gcc jni.c -E


i.e. without any -I switches
Comment 21 Tom "spot" Callaway 2009-03-02 19:56:54 EST
Well, I did that. I am paying attention. :)

The first one fails to find jni.h because it is not in a standard include path. If I pass -I%{java_home}/include/ to that test, it fails to find jni_md.h, because it is in -I%{java_home}/include/linux. If I pass both of those include directives, it builds fine.

My best guess is that something used to pull in libgcj-devel as a dependency and it has been migrated to openjdk in f11. Since, the configure script has no logic to look in the openjdk include directories, we need to pass those directories to configure.

Thus, the bug I've pointed out, where it is impossible to pass JAVA_INCLUDES to configure. I am able to hack it into configure with some clever sed invocations to get it building again, but as I said before, that isn't an appropriate upstream fix. Something like a --with-java-includes= would do the trick. Alternately, it might be possible to ask the openjdk where the headers are installed (although, I can't seem to find anything inside of it that provides that information, except for the rpm macros).
Comment 22 John Ellson 2009-03-02 20:24:39 EST
>I am paying attention. :)
I know.

>The first one fails to find jni.h....
   
What first one?   I was just saying that the code in Comment #20 *finds* jni.h
on my system from the command line without any -I.

So my conclusion is that, as of recently, koji is missing a BR that duplicates that.

There is no need to modify the include path if we can restore the working one.


> My best guess is that something used to pull in libgcj-devel as a dependency
> and it has been migrated to openjdk in f11.

OK

> Since, the configure script has no
> logic to look in the openjdk include directories, we need to pass those
> directories to configure.

Not so. It would be simpler to find what BR restores jni.h to the default include path.

Is it java-1.6.0-openjdk-devel?  (That would be really ugly with that embedded version number.  Its guaranteed to break again in the future.)

I'd be happiest with some form of introspection technique where running a small java program would tell configure where its headers were.   Any suggestion who might know how to do that?
Comment 23 Tom "spot" Callaway 2009-03-02 20:52:58 EST
Okay, let me try to explain.

Originally, the only FOSS implementation of java was libgcj. It wasn't bad, but it certainly wasn't complete. Then, Sun open-sourced their JDK/JRE. It was a lot more complete than libgcj, and almost all work on libgcj moved over to cleaning up and improving openJDK (the name for the open sourced Sun JDK/JRE). Over the course of the last several releases, the Java folks have been porting things off of libgcj and over to the openjdk. Eventually, libgcj is going to be obsolete and everything will be using openjdk. Thus, it doesn't make any sense to use libgcj.

libgcj used to put its headers in /usr/include. This is why on your system (with libgcj-devel installed), your test case has no trouble finding jni.h. 

However, openjdk doesn't put its headers in /usr/include. For better or worse, that's how it works. The openjdk devel package (java-1.6.0-openjdk-devel) has some provides and rpm macros that come with it to make it easier for packagers to use it. For example, it provides "java-devel", so we don't have to worry about the ugly embedded version number, we can just say "BuildRequires: java-devel". It also gives us an rpm macro to the jre home, commonly known in the Java universe as "JAVA_HOME". This macro is %{java_home}, and it will always tell us where to find the openjdk headers (in %{java_home}/include & %{java_home}/include/linux). When I try to build the test case with openjdk's devel package installed (and without the libgcj-devel package installed), it cannot find jni.h, because it is not in /usr/include. When I pass it -I%{java_home}/include/, it finds jni.h, but cannot find jni_md.h (because it is in %{java_home}/include/linux). Passing both sets of -I options enables the test case to compile properly.

So, now, lets talk about how this built before. In the long long ago, the "java-devel" provide came out of libgcj-devel. At some point (not sure when), it moved from libgcj-devel into java-1.6.0-openjdk-devel. This either happened recently, causing graphviz to stop building, or at some longer ago point, but it was obscured by dependencies.

Basically, the way that koji works is that it pulls in ONLY the packages listed by BuildRequires and a bare bare minimum OS environment and then builds the package in that chroot. (mock actually does this for koji, but I digress). If one of the BuildRequires (or one of the packages in the dependency chain) depended on libgcj-devel, it would get pulled into the chroot, and the jni.h would be found). I'm not sure whether that was happening or not, but it is certainly possible. Needless to say, this is not happening anymore, probably because all of the BuildRequires are using openjdk for their Java needs.

Taking all of these as "facts of life", we need a way to tell configure that when it tries to check for jni.h, it needs to use special include flags (and that those include flags need to be saved and used later when we build the actual graphviz java bits). Right now, there is no clean way to do this. The only way to do this is to hack them into configure with sed. I have this hack working right now, and a new graphviz (with your patches) will be hitting rawhide tonight, barring any additional wackiness.

Since we know that as other distributions migrate to openjdk, they will also need to specify the location of the java includedirs, it makes sense for upstream to patch configure to permit passing that information to configure, just as it does now for things like zlib (e.g. --with-zincludedir=). The best part is that there seems to be a variable in place to hold this information, JAVA_INCLUDES, but it is overwritten to either the OSX path or NULL, regardless of what I pass at configure invocation. If it didn't set it empty, and used what I passed like this:

JAVA_INCLUDES="-Ifoo -Ibar" ./configure

I'd have a simple workaround that would work without hackery. But it doesn't work that way, and my autoconf kung-fu is weak.

Do you understand things a bit better now? :)
Comment 24 Tom "spot" Callaway 2009-03-02 20:55:54 EST
Oh, and to answer your question:

> I'd be happiest with some form of introspection technique where running a small
> java program would tell configure where its headers were.   Any suggestion who
> might know how to do that?

This would make the most sense, but I can't find anything that provides this. The next best thing is my observation that on all of Fedora's platforms (i586, x86_64, ppc, ppc64), the java_home seems to be available (via symlinks) at: /usr/lib/jvm/java/ and that the headers are all in either /usr/lib/jvm/java/include/ or /usr/lib/jvm/java/include/linux. It is probably safe to check those directories and add them as includedirs if they exist.
Comment 25 John Ellson 2009-03-02 21:43:43 EST
> The next best thing is my observation that on all of Fedora's platforms (i586,
> x86_64, ppc, ppc64), the java_home seems to be available (via symlinks) at:
> /usr/lib/jvm/java/ and that the headers are all in either
> /usr/lib/jvm/java/include/ or /usr/lib/jvm/java/include/linux. It is probably
> safe to check those directories and add them as includedirs if they exist.


Agreed.  I checked that also.  Thats probably what I'll get configure to look for in the next release.  And I'll add an override.
Comment 26 Tom "spot" Callaway 2009-03-02 22:00:49 EST
Thanks John! graphviz-2.20.3-3.fc11 is built in rawhide, closing out this bug.

Note You need to log in before you can comment on or make changes to this bug.