Project

General

Profile

Bug #2073

wrong position for #include <sys/types.h> in network_backends.h

Added by makoe over 7 years ago. Updated about 1 year ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
core
Target version:
Start date:
2009-09-30
Due date:
% Done:

100%

Estimated time:
0.00 h
Missing in 1.5.x:

Description

Hello everybody,

I use lighttpd with linux 2.6 on a embedded plattform.
Compiling network.c, <sys/type.h> are included bevore "config.h", so _GNU_SOURCE is not defined for <sys/types.h>. Compiling network_linux_sendfile.c, <sys/types.h> is included after "config.h" and _GNU_SOURCE is defined. The problem for my system, I do not use large file support (configure ... --enable-lfs=no), but I do use linux_sendfile, (but not sendfile64). If _GNU_SOURCE is defiend in <sys/types.h>, from features.h you will get _LARGEFILE_SOURCE defiend.

In network_backend.h:

[...]

#if defined HAVE_SYS_SENDFILE_H && defined HAVE_SENDFILE && (!defined _LARGEFILE_SOURCE || defined HAVE_SENDFILE64) && defined HAVE_WRITEV && defined(linux) && !defined HAVE_SENDFILE_BROKEN
  1. define USE_LINUX_SENDFILE
  2. include <sys/sendfile.h>
  3. include <sys/uio.h>
    #endif

[ ... ]

In network.c HAVE_SENDFILE_LINUX is defiend and in network_linux_sendfile.c it is not, so the function network_write_chunkqueue_linuxsendfile is not compiled, I get unresolved errors of course. The solution for me was to move #include <sys/types.h> in fornt of #include "config.h".

Regards, Markus

diff_position_include_sys_types.diff View (644 Bytes) makoe, 2009-09-30 10:27

Associated revisions

Revision 3113 (diff)
Added by stbuehler about 1 year ago

consistent inclusion of config.h at top of files (fixes #2073)

From: Glenn Strauss <>

Revision 8abd06a7 (diff)
Added by gstrauss about 1 year ago

consistent inclusion of config.h at top of files (fixes #2073)

From: Glenn Strauss <>

git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3113 152afb58-edef-0310-8abb-c4023f1b3aa9

History

#1 Updated by stbuehler over 7 years ago

I think that is cheating with the system headers.. imho we should include "config.h" always before any other (system) header.

But you could try to replace _LARGEFILE_SOURCE with _LARGEFILE64_SOURCE in the #if defined [...] line for sendfile.

#2 Updated by gstrauss about 1 year ago

@Markus, it would be more consistent for your build if you edited config.h and commented out the define of _GNU_SOURCE

@stbuehler wrote:

imho we should include "config.h" always before any other (system) header.

Would you please be more specific about what you'd like to see for including config.h before other system headers?
Do you mean #include config.h" at the beginning of every src/*.c and src/*.y? It seems like this is straightforward to do, so I'll prepare a patch once a convention is chosen.

#3 Updated by stbuehler about 1 year ago

Hm. I think including a "first.h" header, which then includes "config.h" if it is available and defines the features macros _GNU_SOURCE and __USE_GNU (from settings.h) would be a good start. This shouldn't break anything even in the "external sources" like lempar, lemon and splaytree.

#4 Updated by gstrauss about 1 year ago

Submitted pull request https://github.com/lighttpd/lighttpd1.4/pull/41

  • added missing include guards in md5.h and proc_open.h
  • fixed md5.h to get proper definition for USE_OPENSSL
    (now uses openssl MD5 routines, where available; never did so before)
  • added #include "first.h" after include guards to *.h
    (could have been scripted, but instead manually reviewed for consistency)
    (e.g. see the header file fixes above)
  • added #include "first.h" to *.c using:
      perl -pi -e 'BEGIN { $/ = undef; } s/\A/#include "first.h"\n\n/s' *.c
    
  • adjusted #include "first.h" in lempar.c (template for code generated from .y)
  • removed #include "first.h" from splaytree.c (third-party)
  • created first.h where config.h is included and _GNU_SOURCE is defined
  • removed #include "config.h" from *.[ch]
  • removed unused defines in settings.h

note:
on some platforms, might need to update build files to link modules using md5.[ch] with openssl (or disable my changes above which use openssl MD5 when available).

#5 Updated by stbuehler about 1 year ago

  • Target version set to 1.4.40

#6 Updated by stbuehler about 1 year ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Applied in changeset r3113.

Also available in: Atom