Project

General

Profile

Actions

Bug #3132

closed

Solaris little nit build fix and startup fix

Added by devnexen about 2 years ago. Updated about 2 years ago.

Status:
Fixed
Priority:
Normal
Category:
build_cmake
Target version:
ASK QUESTIONS IN Forums:
No

Description

- this time, based on personal/gstrauss/master branch
- commit message explaining the reasonings but expaning a bit.
At startup, lighttpd after parsing the config, does not start, happening while trying to open the /dev/null device

lighttpd -D -f /etc/lighttpd/1.4/lighttpd.conf 
2022-01-04 15:07:07: (/export/home/dcarlier/Contribs/lighttpd1.4/src/server.c.1237) opening /dev/null failed: Number of symbolic links encountered during path name traversal exceeds MAXSYMLINKS

however this is not a new issue, the actual illumos lighttpd package (1.4.55) has the same


/usr/lighttpd/1.4/sbin/lighttpd -v
lighttpd/1.4.55 (ssl) - a light and fast webserver

/usr/lighttpd/1.4/sbin/lighttpd -D -f /etc/lighttpd/1.4/lighttpd.conf 
2022-01-04 15:09:00: (server.c.1167) opening /dev/null failed: Number of symbolic links encountered during path name traversal exceeds MAXSYMLINKS

Files

Actions #1

Updated by gstrauss about 2 years ago

  • Category set to build_cmake
  • Target version changed from 1.4.xx to 1.4.64

Please provide ls -l /dev/null (and the resulting chain) on Illumos, for inspection.

The unrelated patch for an unused variable is already on my windows port toy branch (which you can not see), and will be addressed in the future.
However, it is more concerning that IPv6 support was not detected on Illumos. I don't have a testbed for Illumos, so would appreciate if you would look into that further.

Actions #2

Updated by gstrauss about 2 years ago

At startup, lighttpd after parsing the config, does not start, happening while trying to open the /dev/null device

...

however this is not a new issue, the actual illumos lighttpd package (1.4.55) has the same

Such a startup error suggests that either your system is different, or that the packager who created the lighttpd package on Illumos did not run the lighttpd 'make check' build tests, and that nobody is using that lighttpd package on Illumos.

Actions #3

Updated by devnexen about 2 years ago

dcarlier@openindianavbox:~$ ls -l /dev/null
lrwxrwxrwx   1 root     root          27 Dec 18 14:41 /dev/null -> ../devices/pseudo/mm@0:null

the package might not have been tested really even I had to change the conf to make it work, e.g. server.event-handler had no chance to work on illumos.

as for ipv6, on cmake the check fails :

Undefined                       first referenced
 symbol                             in file
in6addr_any                         CMakeFiles/cmTC_b1452.dir/src.c.o
ld: fatal: symbol referencing errors. No output written to cmTC_b1452
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_b1452.dir/build.make:99: cmTC_b1452] Error 1
gmake[1]: Leaving directory '/export/home/dcarlier/Contribs/lighttpd1.4/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:127: cmTC_b1452/fast] Error 2

Source file was:

        #include <sys/types.h>
        #include <sys/socket.h>
        #include <netinet/in.h>

        int main() {
                struct sockaddr_in6 s; struct in6_addr t=in6addr_any; int i=AF_INET6; s; t.s6_addr[0] = 0;
                return 0;
        }

seems on solaris it needs CMAKE_REQUIRED_LIBRARIES set to our usual socket/nsl libraries duo.

as in

set(CMAKE_REQUIRED_LIBRARIES "socket nsl") before this.

on meson the same test passes.

Actions #4

Updated by gstrauss about 2 years ago

- commit message explaining the reasonings but expaning a bit.

BTW, I don't know where you are committing things, but that information is not in the attached file, and has not been available to me in any of your previous patches.

Actions #5

Updated by devnexen about 2 years ago

ah I see, not visible if you re using the web UI but if you download the file you can see normally (I commit locally and do git format-patch so the commit message ought to be).

Actions #6

Updated by gstrauss about 2 years ago

ah I see, not visible if you re using the web UI but if you download the file you can see normally (I commit locally and do git format-patch so the commit message ought to be).

I hadn't realized that the redmine web interface was hiding that info. Thanks for pointing that out. It's a few extra steps to download and view in a shell, but I'll look for that extra info going forwards.

I pushed a commit to my dev branch which should address these.

Actions #7

Updated by gstrauss about 2 years ago

  • Status changed from New to Patch Pending
Actions #8

Updated by devnexen about 2 years ago

Little mistake from my part, CMAKE_REQUIRED_LIBRARIES is a list of then it is

set(CMAKE_REQUIRED_LIBRARIES "socket;nsl") then now I see ipv6 is detected. other than that the rest of your changes work.

Question since in the root CMakeLists.txt you set CMAKE_C_STANDARD, is the cmake_minimum_required set to 2.8.2 still holding true if someone use cmake < 3.0 for ex ?

Actions #10

Updated by gstrauss about 2 years ago

Question since in the root CMakeLists.txt you set CMAKE_C_STANDARD, is the cmake_minimum_required set to 2.8.2 still holding true if someone use cmake < 3.0 for ex ?

Since CMAKE_C_STANDARD was introduced in CMake 3.1, I assume that it has no effect on earlier versions of CMake, but I did not explicitly test that.

Thanks for the set(CMAKE_REQUIRED_LIBRARIES "socket;nsl") correction. This has been fixed on my dev branch.

Actions #11

Updated by devnexen about 2 years ago

your last version works for me.

Actions #12

Updated by devnexen about 2 years ago

gstrauss wrote in #note-10:

Question since in the root CMakeLists.txt you set CMAKE_C_STANDARD, is the cmake_minimum_required set to 2.8.2 still holding true if someone use cmake < 3.0 for ex ?

Since CMAKE_C_STANDARD was introduced in CMake 3.1, I assume that it has no effect on earlier versions of CMake, but I did not explicitly test that.

True. I was thinking about, for example, CentOs 7 (supported until 2024) with cmake 2.8.12 but having a C 11 capable compiler from a third party repository thus extensions not enabled but I also see in a known third party repository a newer version of cmake so should be fine finally.

Actions #13

Updated by gstrauss about 2 years ago

  • Status changed from Patch Pending to Fixed
Actions

Also available in: Atom