xulrunner-1.9.1 is putting jsapi.h and the like in /usr/include/xulrunner-1.9.1/unstable/ .. however pkg config --cflags mozilla-js only shows "-DXP_UNIX -DJS_THREADSAFE -I/usr/include/xulrunner-1.9.1/stable -I/usr/include/nspr" .. hence stuff like libproxy depending on jsapi.h etc fail to compile hence the emerge fails as ... /bin/sh ../../libtool --tag=CC --mode=compile i686-pc-linux-gnu-gcc -DPACKAGE_NAME=\"libproxy\" -DPACKAGE_TARNAME=\"libproxy\" -DPACKAGE_VERSION=\"0.2.3\" -DPACKAGE_STRING=\"libproxy\ 0.2.3\" -DPACKAGE_BUGREPORT=\"nathaniel@natemccallum.com\" -DPACKAGE=\"libproxy\" -DVERSION=\"0.2.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DSTDC_HEADERS=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -I. -I../../src/lib -DXP_UNIX -DJS_THREADSAFE -I/usr/include/xulrunner-1.9.1/stable -I/usr/include/nspr -g -std=c99 -march=core2 -mtune=core2 -O2 -pipe -fomit-frame-pointer -DPLUGINDIR=\"/usr/lib/libproxy/0.2.3/plugins\" -DSYSCONFDIR=\"/etc\" -D_POSIX_C_SOURCE=1 -MT mozjs_la-mozjs.lo -MD -MP -MF .deps/mozjs_la-mozjs.Tpo -c -o mozjs_la-mozjs.lo `test -f 'mozjs.c' || echo './'`mozjs.c mozjs.c:32:19: error: jsapi.h: No such file or directory mozjs.c:35: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘dnsResolve’ mozjs.c:70: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘myIpAddress’ mozjs.c:83: error: expected specifier-qualifier-list before ‘JSRuntime’ Reproducible: Always Steps to Reproduce: 1.Emerge xulrunner-1.9.1rc1 2.Emerge libproxy
(In reply to comment #0) > xulrunner-1.9.1 is putting jsapi.h and the like in > /usr/include/xulrunner-1.9.1/unstable/ .. however pkg config --cflags > mozilla-js only shows "-DXP_UNIX -DJS_THREADSAFE > -I/usr/include/xulrunner-1.9.1/stable -I/usr/include/nspr" .. hence stuff like > libproxy depending on jsapi.h etc fail to compile > > > hence the emerge fails as ... > > /bin/sh ../../libtool --tag=CC --mode=compile i686-pc-linux-gnu-gcc > -DPACKAGE_NAME=\"libproxy\" -DPACKAGE_TARNAME=\"libproxy\" > -DPACKAGE_VERSION=\"0.2.3\" -DPACKAGE_STRING=\"libproxy\ 0.2.3\" > -DPACKAGE_BUGREPORT=\"nathaniel@natemccallum.com\" -DPACKAGE=\"libproxy\" > -DVERSION=\"0.2.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 > -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 > -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 > -DLT_OBJDIR=\".libs/\" -DSTDC_HEADERS=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 > -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -I. -I../../src/lib -DXP_UNIX > -DJS_THREADSAFE -I/usr/include/xulrunner-1.9.1/stable -I/usr/include/nspr -g > -std=c99 -march=core2 -mtune=core2 -O2 -pipe -fomit-frame-pointer > -DPLUGINDIR=\"/usr/lib/libproxy/0.2.3/plugins\" -DSYSCONFDIR=\"/etc\" > -D_POSIX_C_SOURCE=1 -MT mozjs_la-mozjs.lo -MD -MP -MF .deps/mozjs_la-mozjs.Tpo > -c -o mozjs_la-mozjs.lo `test -f 'mozjs.c' || echo './'`mozjs.c > > > mozjs.c:32:19: error: jsapi.h: No such file or directory > mozjs.c:35: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or > ‘__attribute__’ before ‘dnsResolve’ > mozjs.c:70: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or > ‘__attribute__’ before ‘myIpAddress’ > mozjs.c:83: error: expected specifier-qualifier-list before ‘JSRuntime’ > > > Reproducible: Always > > Steps to Reproduce: > 1.Emerge xulrunner-1.9.1rc1 > 2.Emerge libproxy > The file is still in development, an unstable state. No package should use it unless they are in development as well and not really ready for the users. any package that depends on such header should depend on an older version of xulrunner.
I have also just tested libproxy-0.2.3 and it compiles fine against xulrunner-1.9.1_rc1
I went ahead and looked at this closer, I did not like the fix they used in the main tree, so I went ahead and fixed it in the mozilla overlay. This is a duplicate of bug #259178 tho.
(In reply to comment #2) > I have also just tested libproxy-0.2.3 and it compiles fine against > xulrunner-1.9.1_rc1 > libproxy-0.2.3-r1 didn't compile with xulrunner-1.9.11 for me. I couldn't find xulrunner-1.9.1-rc1 to try. Where did you find xulrunner-1.9.1-rc1?
(In reply to comment #1) > (In reply to comment #0) > > The file is still in development, an unstable state. No package should use it > unless they are in development as well and not really ready for the users. any > package that depends on such header should depend on an older version of > xulrunner. > I have the same problem. Here is what is pulling it in (I'm running ~x86): These are the packages that would be merged, in reverse order: Calculating dependencies... done! [nomerge ] app-office/gnucash-2.2.9-r1 USE="ofx quotes -chipcard -debug -doc -hbci" [nomerge ] gnome-extra/gtkhtml-3.26.2 USE="-glade" [nomerge ] net-libs/libsoup-2.26.2 USE="gnome ssl -debug -doc" [ebuild U ] net-libs/libproxy-0.2.3-r1 [0.2.3] USE="kde python xulrunner -gnome -networkmanager -webkit" 0 kB
For me, with net-libs/xulrunner-1.9.0.11, net-libs/libproxy-0.2.3-r1 fails in included file /usr/include/xulrunner-1.9/unstable/jstypes.h complaining "Must define one of XP_BEOS, XP_OS2, XP_WIN or XP_UNIX". Impatient to proceed with my system ugrade and tired of wrestling with several other problems before, I resorted to quick and dirty hack and put #define XP_UNIX right after #ifndef jstypes_h___ #define jstypes_h___ into the /usr/include/xulrunner-1.9/unstable/jstypes.h file. Successful compilation then removed the build.log of my previous failure, so I now cannot (until I feel like to do some more work) report what file in the libproxy sources includes jstype.h, and indicate thus where the XP_UNIX definition should be correctly inserted to by a proper libproxy patch. Looks like the xulrunner headers expect XP_<OS_type> to be defined but libproxy fails to do so.
Bug 275318 deals with this as well with elaborate descriptions what's going on. Marking as duplicate *** This bug has been marked as a duplicate of bug 275318 ***
(In reply to comment #6) > Successful > compilation then removed the build.log of my previous failure, so I now cannot > (until I feel like to do some more work) report what file in the libproxy > sources includes jstype.h, and indicate thus where the XP_UNIX definition > should be correctly inserted to by a proper libproxy patch. > > Looks like the xulrunner headers expect XP_<OS_type> to be defined but libproxy > fails to do so. libproxy properly asks pkg-config for the package "mozilla-js", which has all this -DXP_UNIX stuff in Cflags already, and so XP_UNIX IS defined when compiling libproxy without configure.ac patches. The problem is that -r1 got patches to workaround another problem somewhat wrongly - that we put javascript headers in unstable/ on Gentoo, but keep mozilla-js.pc pointing at stable/ The bug I marked this one as duplicate has patches to workaround that properly (as long as you have /bin/sh as bash, it needs better way to replace some stuff in a variable that is POSIX compatible) until mozilla-js.pc is as it is currently, both in 1.9.0.x and 1.9.1
> Impatient to proceed with my system ugrade and tired of wrestling with several > other problems before, I resorted to quick and dirty hack and put > > #define XP_UNIX > > right after > > #ifndef jstypes_h___ > #define jstypes_h___ I also had to create the following links to complete libproxy compilation : ln -s /usr/lib/libplds4.so.8 /usr/lib/libplds4.so.6 ln -s /usr/lib/libnspr4.so.8 /usr/lib/libpnspr4.so.6
