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 511189 - Inconsistent flag-passing to neon build
Inconsistent flag-passing to neon build
Status: RESOLVED WONTFIX
Product: gnome-vfs
Classification: Deprecated
Component: Build
2.20.x
Other Mac OS
: Normal normal
: ---
Assigned To: gnome-vfs maintainers
gnome-vfs maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2008-01-22 07:13 UTC by Daniel Macks
Modified: 2018-08-17 13:52 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel Macks 2008-01-22 07:13:03 UTC
gnome-vfs-2.20.1/imported/neon/Makefile.am has as part of INCLUDES:

	$(LIBGNOMEVFS_CFLAGS)			\

Does a low-level convenience library really need all the glib/gnome/etc -I flags for the full libgnomevfs? Conversely, if gnome-vfs is built with openssl, neon uses some symbols from openssl but does not specify any linker flags for it. Likewise for gssapi (where GSSAPI_CFLAGS *is* used but not _LIBS).
Comment 1 Daniel Macks 2008-01-22 07:30:08 UTC
Actually, gssapi is even more confusing. The autoconf VFS_NEON_BUNDLED macro tries to slurp the GSSAPI_ flags (previously determined by configure) into NEON_, but is broken by a typo:

	NEON_CFLAGS="$NEON_CFALGS $GSSAPI_CFLAGS"
	NEON_LIBS="$NEON_LIBS $GSSAPI_LIBS"

(change CFALGS -> CFLAGS).

So it looks like GSSAPI_CFLAGS is passed *twice* to the neon build (both NEON_CFLAGS and GSSAPI_CFLAGS are in INCLUDES in neon/Makefile.am). For clarity and self-consistency, I think VFS_NEON_BUNDLED  should not put GSSAPI_ into NEON_ at all, but rather have neon/Makefile.am explicitly pass GSSAPI_CFLAGS and GSSAPI_LIBS. 

Similarly, neon/Makefile.am should not pass LIBGNOMEVFS_CFLAGS and should pass OPENSSL_CFLAGS and OPENSSL_LIBS.

Finally, neon/Makefile.am INCLUDES needs to be shuffled so that all local -I come before any global ones: if a _CFLAGS happens to include a -I for an installed support library that also contains the headers for gnome-vfs (or whatever) itself, *that* header would be found instead of the one in the source directory.
Comment 2 Daniel Macks 2008-01-22 08:15:20 UTC
Ah, I see that neon *does* need glib. So while LIBGNOMEVFS_CFLAGS might be overkill, it is needed, and that variable does contain OPENSSL_CFLAGS. So "consistency" *might* be for NEON_ to contain GSSAPI and LIBGNOMEVFS_ to contain OPENSSL_ and then pass (in neon/Makefile.am) both _CFLAGS and _LIBS for both LIBGNOMEVFS_ and NEON_ but no explicit GSSAPI_ or LIBGNOMEVFS_?
Comment 3 André Klapper 2018-08-17 13:52:51 UTC
gnome-vfs got deprecated in 2008.

gnome-vfs is not under active development anymore and had its last code changes
in 2011. Its codebase has been archived:
https://gitlab.gnome.org/Archive/gnome-vfs/commits/master

gio (in glib) and gvfs are its successors. See https://developer.gnome.org/gio/stable/ch33.html and https://people.gnome.org/~gicmo/gio-migration-guide/ for porting info.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent + supported version of glib/gio/gvfs. Thanks!