After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 622392 - build failure due to missing nspr includes
build failure due to missing nspr includes
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: general
2.32.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
: 621148 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-06-22 13:19 UTC by Jonathon Jongsma
Modified: 2013-09-14 16:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fix build (2.97 KB, application/octet-stream)
2010-06-22 13:19 UTC, Jonathon Jongsma
Details

Description Jonathon Jongsma 2010-06-22 13:19:04 UTC
Created attachment 164305 [details]
fix build

Several convenience libraries failed to build because they couldn't find <prio.h>.  Adding E_UTILS_CFLAGS to each of these libraries works around the issue for now.   The proper fix is probably to add the nspr includes to camel-1.2.pc or don't include the ssl headers in camel.h unconditionally and create a separate camel-ssl.pc that pulls in the nspr libraries.
Comment 1 Matthew Barnes 2010-06-22 13:34:21 UTC
It looks like the proper nss/nspr flags are already present in camel-1.2.pc.

One thing that caught my eye is camel-tcp-stream-ssl.h wraps everything in a #ifdef HAVE_SSL / #endif block.  HAVE_SSL is a really generic name for a public header file.  In fact Evolution defines its own HAVE_SSL and if Camel and Evolution aren't in agreement on SSL support that could cause problems.

Would it make sense to add something like -DCAMEL_SSL_SUPPORT to Cflags in camel-1.2.pc if Camel is configured with NSPR support, and then use that throughout Camel instead of HAVE_SSL?
Comment 2 Jonathon Jongsma 2010-06-22 13:44:46 UTC
hm, my camel-1.2.pc doesn't seem to have anything related to nss/nspr:

----
prefix=/home/jonathon/.jhbuild-prefix
exec_prefix=${prefix}
libdir=/home/jonathon/.jhbuild-prefix/lib64
includedir=${prefix}/include

privlibdir=${libdir}/evolution-data-server-3.0
privincludedir=${includedir}/evolution-data-server-3.0

Name: camel
Description: the Evolution MIME message handling library
Version: 2.31.4
Requires: glib-2.0 libedataserver-1.2 sqlite3  
Libs: -L${libdir} -lcamel-1.2
Cflags: -I${privincludedir}
----

Maybe I built camel without the right options ?
Comment 3 Matthew Barnes 2010-06-22 18:18:41 UTC
Means "mozilla_nss" and "mozilla_nspr" automake variables aren't getting set correctly when running configure on your system.  Does your distro (Debian, right?) not provide pkg-config files for nss/nspr?  If so, you may be exercising a different logic path than I am on Fedora.

The camel.pc.in file does have spots for them:

Name: camel
Description: the Evolution MIME message handling library
Version: @VERSION@
Requires: glib-2.0 libedataserver-@API_VERSION@ sqlite3 @mozilla_nss@ @mozilla_nspr@
Comment 4 Matthew Barnes 2010-06-24 21:51:26 UTC
Can you tell me exactly what options you're passing to configure and I'll try to reproduce this on my Debian machine at home?
Comment 5 Jonathon Jongsma 2010-06-24 23:31:19 UTC
I'm away from my computer til next week. I'll try to get the info as soon as I can.
Comment 6 Matthew Barnes 2010-06-27 11:57:33 UTC
Think I figured it out:

http://git.gnome.org/browse/evolution-data-server/commit/?id=1c79f8a68d546f7d83f6e4e60576d602b7d91135

We can reopen if that doesn't fix it 100%.
Comment 7 Matthew Barnes 2010-06-27 12:44:30 UTC
Oh, my commit message is mistaken.  Debian -does- ship pkg-config files for nss and nspr.  It seems if you just leave off all the --with-nss-* / --with-nspr-* configure options, it should detect and use the pkg-config files on its own.  But well, at least the "no pkg-config files present" use case is fixed now.

Would still like to know what flags you're passing, when you can.  And whether applying any of this works for you.
Comment 8 Matthew Barnes 2010-06-27 12:45:34 UTC
*** Bug 621148 has been marked as a duplicate of this bug. ***
Comment 9 Jonathon Jongsma 2010-06-28 14:38:04 UTC
aha, so it turns out that I was unwittingly using an old workaround in my .jhbuildrc for evolution-data-server and specifying the nss/nspr stuff manually.  Your commit fixes this case.  I can try to test the other use case later, but for now I think you can assume it's fixed.
Comment 10 Matthew Barnes 2010-07-22 14:26:28 UTC
*** Bug 625039 has been marked as a duplicate of this bug. ***