Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-12778

mariadb-10.1 FTBFS on GNU/Hurd due to use of PATH_MAX

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Fixed
    • 10.1.23
    • 10.1.26, 5.5.57, 10.0.32, 10.2.8
    • Compiling
    • None
    • Debian GNU/Hurd i386 and DEbian GNU/Linux amd64

    Description

      Attached are patches to make mariadb-10.1 to build on GNU/Hurd. Unfortunately
      there are still some warnings to fix and the testsuite fails, and has been
      removed with debian/rules patch. Attached is also an updated symbols file, the
      link given in debian/ points to a file having three symbols not in the Hurd
      version.
      The patched package has also been successfully built on GNU/Linux amd64 with
      pbuilder.cmake.patch defines the system name GNU, tries to disable dtrace (which is Linux
      only from systemtap-sdt-dev) and add a check for HAVE_SYS_POLL_H, see
      path_max.patch. Unfortunately disabling dtrace did not work, I had to uninstall
      systemtap-sdt-dev, I wonder why?
      path_max.patch defines GNU_SOURCE if not already defined, avoids a FreeBSD-
      specific definition of O_PATH, and fixes PATH_MAX issues in files
      /mysys/mysys_priv.h, sql/wsrep_binlog.cc and extra/mariabackup/backup_copy.cc.
      The POLL stuff in storage/mroonga/vendor/groonga/lib/grn_com.h and
      storage/mroonga/vendor/groonga/lib/com.c fixes the USE_POLL case. That case is
      not properly handled in the upstream code. GNU/Hurd could of course use
      USE_SELECT, but since the OS is detected as using POLL, that choice is fixed
      too.

      The current debian version is at 10.1.23-6. Since there is a freeze going on and since the GNU patches are also affecting other OSes it would be nice if the patches are accepted upstream. If so, they are easily motivation to be accepted in Debian, including the imminent Stretch release.

      Attachments

        1. cmake.patch
          2 kB
        2. CMakeCache.txt
          93 kB
        3. hurd-pathmax.diff
          1 kB
        4. path_max_new.patch
          9 kB
        5. path_max.patch
          9 kB

        Activity

          Ascending order - Click to sort in descending order
          View 14 older comments
          gnu_srs Svante Signell added a comment -

          Sorry about O_EXEC: It is defined on GNU/Hurd but defining O_PATH would make my_open_parent_dir_nosymlinks() used in macro NOSYMLINK_FUNCTION_BODY(AT,NOAT) instead of the definition using realpath().

          I'll be back on the _GNU_SOURCE later. Have to recompile without _GNU_SOURCE and issue gcc -E ... to see where things go wrong.

          gnu_srs Svante Signell added a comment - Sorry about O_EXEC: It is defined on GNU/Hurd but defining O_PATH would make my_open_parent_dir_nosymlinks() used in macro NOSYMLINK_FUNCTION_BODY(AT,NOAT) instead of the definition using realpath(). I'll be back on the _GNU_SOURCE later. Have to recompile without _GNU_SOURCE and issue gcc -E ... to see where things go wrong.
          serg Sergei Golubchik added a comment -

          Okay, I see. So GNU/Hurd does have O_EXEC. Why do you try to avoid my_open_parent_dir_nosymlinks()? Because O_EXEC has a different semantics on GNU/Hurd? What semantics is it? May be, because GNU/Hurd does not have openat?

          serg Sergei Golubchik added a comment - Okay, I see. So GNU/Hurd does have O_EXEC . Why do you try to avoid my_open_parent_dir_nosymlinks() ? Because O_EXEC has a different semantics on GNU/Hurd? What semantics is it? May be, because GNU/Hurd does not have openat ?
          gnu_srs Svante Signell added a comment -

          From what I remember that function, my_open_parent_dir_nosymlinks(), does introduce another PATH_MAX issue (sigh). I did not invest the time to avoid another PATH_MAX issue by making it PATH_MAX -free. OK; I was lazy, admitted.

          (Will you ever learn not to use PATH_MAX? Perhaps using a fixed size if you want to avoid malloc) See http://insanecoding.blogspot.se/2007/11/pathmax-simply-isnt.html again)

          gnu_srs Svante Signell added a comment - From what I remember that function, my_open_parent_dir_nosymlinks(), does introduce another PATH_MAX issue (sigh). I did not invest the time to avoid another PATH_MAX issue by making it PATH_MAX -free. OK; I was lazy, admitted. (Will you ever learn not to use PATH_MAX? Perhaps using a fixed size if you want to avoid malloc) See http://insanecoding.blogspot.se/2007/11/pathmax-simply-isnt.html again)
          serg Sergei Golubchik added a comment - - edited

          Okay. I've fixed my_open_parent_dir_nosymlinks() not to use PATH_MAX. You should try to use my_open_parent_dir_nosymlinks() if possible, because it's the only race-condition safe way to open symlinked tables.

          As far as your poll/select changes are concerned, I don't understand them either
          You've changed

          #ifdef USE_SELECT
          		 
            /* use select */
          		 
          #else
          		 
          # ifdef USE_EPOLL
          		 
            /* use epoll */
          		 
          # else
          		 
          #  ifdef USE_KQUEUE
          		 
            /* use kqueue */
          		 
          #  else
          		 
            /* use poll */
          		 
          #  endif
          		 
          # endif
          		 
          #endif

          to

          #ifdef USE_SELECT
          		 
            /* use select */
          		 
          #else
          		 
          # ifdef USE_POLL
          		 
            /* use poll */
          		 
          # else
          		 
          #  ifdef USE_EPOLL
          		 
            /* use epoll */
          		 
          #  else
          		 
              /* use kqueue */
          		 
          #  endif
          		 
          # endif
          		 
          #endif

          but that couldn't have made any difference, because Groonga always defines only one of the four USE_SELECT, USE_POLL, USE_EPOLL, USE_KQUEUE.

          In your case, judging from your CMakeCache.txt, you should have only USE_POLL defined.

          serg Sergei Golubchik added a comment - - edited Okay. I've fixed my_open_parent_dir_nosymlinks() not to use PATH_MAX . You should try to use my_open_parent_dir_nosymlinks() if possible, because it's the only race-condition safe way to open symlinked tables. As far as your poll/select changes are concerned, I don't understand them either You've changed #ifdef USE_SELECT /* use select */ #else # ifdef USE_EPOLL /* use epoll */ # else # ifdef USE_KQUEUE /* use kqueue */ # else /* use poll */ # endif # endif #endif to #ifdef USE_SELECT /* use select */ #else # ifdef USE_POLL /* use poll */ # else # ifdef USE_EPOLL /* use epoll */ # else /* use kqueue */ # endif # endif #endif but that couldn't have made any difference, because Groonga always defines only one of the four USE_SELECT , USE_POLL , USE_EPOLL , USE_KQUEUE . In your case, judging from your CMakeCache.txt , you should have only USE_POLL defined.
          serg Sergei Golubchik added a comment -

          gnu_srs, I'm closing this issue.The subject says "due to use of PATH_MAX" and PATH_MAX related changes are in 5.5.57. 5.5.57 is released now and we cannot have this issue "half-fixed" in one version and "rest-fixed" in the other.

          So let's close this one as "PATH_MAX" problem. And if you need poll/select changes, please, open a new issue for them (and mention this one, so that you wouldn't need to describe everything again).

          serg Sergei Golubchik added a comment - gnu_srs , I'm closing this issue.The subject says "due to use of PATH_MAX" and PATH_MAX related changes are in 5.5.57. 5.5.57 is released now and we cannot have this issue "half-fixed" in one version and "rest-fixed" in the other. So let's close this one as "PATH_MAX" problem. And if you need poll/select changes, please, open a new issue for them (and mention this one, so that you wouldn't need to describe everything again).

          People

            serg Sergei Golubchik
            gnu_srs Svante Signell
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.