Loading ...
Sorry, an error occurred while loading the content.
 

Re: sigaltstack

Expand Messages
  • Johannes Zellner
    ... this hits only FreeBSD. Not Linux. I compile it on FreeBSD now by manually uncommenting the definition in the config file. -- Johannes
    Message 1 of 12 , Nov 30, 2000
      On Fri, Dec 01, 2000 at 06:14:01PM +1100, Matthew Hawkins wrote:
      > I've just subscribed but found this thread in the archives. Sorry about
      > the lack of References: but obviously I don't have the originals ;)
      >
      > Anyway my problem is identical, but I have some further insight Bram and
      > Johannes missed.
      >
      > Johannes is linking against libpython, has obviously compiled it with
      > thread support, and hence -pthread is added to the gcc command line.
      > This makes gcc use libc_r.so, not libc.so, obviously because threaded
      > applications will need the reentrant versions of the functions.
      >
      > The trick is, libc_r does not have sigaltstack(). nm the library.
      > To complicate matters further, it also does not have sigstack() which
      > means simply undefining HAVE_SIGALTSTACK and hence using the alternative
      > init_signal_stack() code will not work.
      >
      > I guess one solution is to compile python without threads support. I
      > doubt this will make for happy python campers ;)
      >
      > Any ideas for a real solution? This hits FreeBSD 4.2 with Python 2.0 as
      > well (aka, my box ;).

      this hits only FreeBSD. Not Linux.
      I compile it on FreeBSD now by manually uncommenting
      the definition in the config file.

      --
      Johannes
    • Matthew Hawkins
      This patch to configure.in fixes the compile-time problem (in a rather hacky way, but hey) ... +++ src/configure.in Fri Dec 1 19:58:10 2000 @@ -1514,6
      Message 2 of 12 , Dec 1, 2000
        This patch to configure.in fixes the compile-time problem (in a rather
        hacky way, but hey)

        --- src/configure.in.vim60n Fri Dec 1 19:58:00 2000
        +++ src/configure.in Fri Dec 1 19:58:10 2000
        @@ -1514,6 +1514,12 @@
        sigaltstack sigstack sigset sigsetjmp sigaction sigvec \
        strcasecmp strerror strftime stricmp strncasecmp strnicmp \
        strpbrk strtol tgetent usleep utime utimes)
        +dnl On FreeBSD libc_r has no sigaltstack() which breaks python support
        +if test "$enable_pythoninterp" = "yes"; then
        + if test "`(uname) 2>/dev/null`" = FreeBSD; then
        + AC_DEFINE(HAVE_SIGALTSTACK, 0, [ We don't want this on FreeBSD with python. ])
        + fi
        +fi

        dnl fstatfs() can take 2 to 4 arguments, try to use st_blksize if possible
        AC_MSG_CHECKING(for st_blksize)



        I'm still quite concerned about the runtime because of the following:

        /usr/local/lib/python2.0/config/libpython2.0.a(posixmodule.o): In function `posix_tempnam':
        posixmodule.o(.text+0x24c2): warning: tempnam() possibly used unsafely; consider using mkstemp()
        /usr/local/lib/python2.0/config/libpython2.0.a(posixmodule.o): In function `posix_tmpnam':
        posixmodule.o(.text+0x256c): warning: tmpnam() possibly used unsafely; consider using mkstemp()
        /usr/lib/libc_r.so: WARNING! setkey(3) not present in the system!
        /usr/lib/libc_r.so: warning: this program uses gets(), which is unsafe.
        /usr/lib/libc_r.so: warning: mktemp() possibly used unsafely; consider using mkstemp()
        /usr/lib/libc_r.so: WARNING! des_setkey(3) not present in the system!
        /usr/lib/libc_r.so: WARNING! encrypt(3) not present in the system!
        /usr/lib/libc_r.so: warning: this program uses f_prealloc(), which is stupid.
        /usr/lib/libc_r.so: WARNING! des_cipher(3) not present in the system!
        /usr/libexec/elf/ld: posixmodule.o: warning: unresolvable relocation against symbol `tempnam' from .text section
        /usr/libexec/elf/ld: posixmodule.o: warning: unresolvable relocation against symbol `tmpnam' from .text section

        (specifically, the bits noted as being stupid, and the unresolvable
        relocations)

        --
        Matt
      • Bram Moolenaar
        Matthew Hawkins wrote: [Note: this is about FreeBSD] ... I recently dived into this problem and discovered what you already knew. I ve reported a problem with
        Message 3 of 12 , Dec 1, 2000
          Matthew Hawkins wrote:

          [Note: this is about FreeBSD]

          > I've just subscribed but found this thread in the archives. Sorry about
          > the lack of References: but obviously I don't have the originals ;)
          >
          > Anyway my problem is identical, but I have some further insight Bram and
          > Johannes missed.
          >
          > Johannes is linking against libpython, has obviously compiled it with
          > thread support, and hence -pthread is added to the gcc command line.
          > This makes gcc use libc_r.so, not libc.so, obviously because threaded
          > applications will need the reentrant versions of the functions.
          >
          > The trick is, libc_r does not have sigaltstack(). nm the library.
          > To complicate matters further, it also does not have sigstack() which
          > means simply undefining HAVE_SIGALTSTACK and hence using the alternative
          > init_signal_stack() code will not work.
          >
          > I guess one solution is to compile python without threads support. I
          > doubt this will make for happy python campers ;)
          >
          > Any ideas for a real solution? This hits FreeBSD 4.2 with Python 2.0 as
          > well (aka, my box ;).

          I recently dived into this problem and discovered what you already knew. I've
          reported a problem with sigaltstack to GNATS, a patch was made by Marcel
          Moolenaar (no relative). Don't know in which release it will appear (probably
          just missed 4.2).

          I've now changed configure to do the test for the presence of sigaltstack()
          with the right library. That means when Vim is compiled with Python, it won't
          use sigaltstack(). But it does compile.

          It's now also possible to run Vim with Perl and Python at the same time.
          I noticed that for Perl "-lc" was added to the linker line, making Vim use
          libc instead of libc_r. This caused weird problems when running Vim
          (compilation didn't complain, which was very confusing!). Lesson learned: you
          can't link with libc if you compiled with -D_THREAD_SAFE.

          You'll see it in version 6.0o in a few days. First have to finish
          reading/writing Unicode files with a BOM...

          --
          ARTHUR: Well, I AM king...
          DENNIS: Oh king, eh, very nice. An' how'd you get that, eh? By exploitin'
          the workers -- by 'angin' on to outdated imperialist dogma which
          perpetuates the economic an' social differences in our society! If
          there's ever going to be any progress--
          The Quest for the Holy Grail (Monty Python)

          /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
          \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
        • Matthew Hawkins
          Non FreeBSD-people, hit d now :) Ignore my last patch, it s bogus (code only checks for it being defined, regardless of whether its set to 1 or 0). This
          Message 4 of 12 , Dec 1, 2000
            Non FreeBSD-people, hit 'd' now :)

            Ignore my last patch, it's bogus (code only checks for it being defined,
            regardless of whether its set to 1 or 0). This escaped because I had
            stupidly left -lc on in the port Makefile so it linked correctly anyway.

            I was just touching up a less bogus patch (removing sigaltstack from
            AC_CHECK_FUNCS when compiling for FreeBSD with python support) which
            works for me, but seeing as Bram has also solved the problem in the mean
            time there's no point me submitting it.

            Just a quick q though, if the threaded python library (or any threaded
            library for that matter) is being linked in, is -pthread necessary all
            the time or just on the final link? Because right now, its only being
            put in on the final link. I haven't seen any problems yet, just
            curious...

            The good news is that I've got GTK support working so with any luck
            David will put it back into the port.

            Cheers,

            --
            Matt
          • Bram Moolenaar
            ... It s needed for the link command only. But the compilation requires -D_THREAD_SAFE. This is easy to do wrong (e.g., when an old .o file is used) and
            Message 5 of 12 , Dec 1, 2000
              Matthew Hawkins wrote:

              > Non FreeBSD-people, hit 'd' now :)
              >
              > Ignore my last patch, it's bogus (code only checks for it being defined,
              > regardless of whether its set to 1 or 0). This escaped because I had
              > stupidly left -lc on in the port Makefile so it linked correctly anyway.
              >
              > I was just touching up a less bogus patch (removing sigaltstack from
              > AC_CHECK_FUNCS when compiling for FreeBSD with python support) which
              > works for me, but seeing as Bram has also solved the problem in the mean
              > time there's no point me submitting it.
              >
              > Just a quick q though, if the threaded python library (or any threaded
              > library for that matter) is being linked in, is -pthread necessary all
              > the time or just on the final link? Because right now, its only being
              > put in on the final link. I haven't seen any problems yet, just
              > curious...

              It's needed for the link command only. But the compilation requires
              -D_THREAD_SAFE. This is easy to do wrong (e.g., when an old .o file is used)
              and there is no warning...

              > The good news is that I've got GTK support working so with any luck
              > David will put it back into the port.

              Was GTK support broken? It always worked for me...

              --
              WOMAN: I didn't know we had a king. I thought we were an autonomous
              collective.
              DENNIS: You're fooling yourself. We're living in a dictatorship. A
              self-perpetuating autocracy in which the working classes--
              WOMAN: Oh there you go, bringing class into it again.
              DENNIS: That's what it's all about if only people would--
              The Quest for the Holy Grail (Monty Python)

              /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
              \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
            • Matthew Hawkins
              ... It seems only if compiling from the port (/usr/ports/editors/vim6). What happens is link.sh removes libXt, and naturally not long after, linking fails.
              Message 6 of 12 , Dec 2, 2000
                On Fri, 01 Dec 2000, Bram Moolenaar wrote:
                > Was GTK support broken? It always worked for me...

                It seems only if compiling from the port (/usr/ports/editors/vim6).
                What happens is link.sh removes libXt, and naturally not long after,
                linking fails. The same thing _dosn't_ happen if one simply compiles
                from the tarball.

                I was fixing this for the port maintainer (not a big fan of GTK) when I
                discovered the sigaltstack thing (I wanted python support in my own
                setup, so I added it in and *boom*).

                My fix for the port issue though is nasty (I brute-force -lXt in if
                building with GTK support) but it works. Hopefully David will accept it
                anyway.

                --
                Matt
              • Bram Moolenaar
                ... I don t see how link.sh can remove a library and make linking fail. If linking fails, link.sh won t remove the library. I m using FreeBSD myself, and it
                Message 7 of 12 , Dec 3, 2000
                  Matthew Hawkins wrote:

                  > On Fri, 01 Dec 2000, Bram Moolenaar wrote:
                  > > Was GTK support broken? It always worked for me...
                  >
                  > It seems only if compiling from the port (/usr/ports/editors/vim6).
                  > What happens is link.sh removes libXt, and naturally not long after,
                  > linking fails. The same thing _dosn't_ happen if one simply compiles
                  > from the tarball.

                  I don't see how link.sh can remove a library and make linking fail. If
                  linking fails, link.sh won't remove the library.

                  I'm using FreeBSD myself, and it all works fine for me. I wonder what strange
                  thing the port does to break it?

                  > I was fixing this for the port maintainer (not a big fan of GTK) when I
                  > discovered the sigaltstack thing (I wanted python support in my own
                  > setup, so I added it in and *boom*).
                  >
                  > My fix for the port issue though is nasty (I brute-force -lXt in if
                  > building with GTK support) but it works. Hopefully David will accept it
                  > anyway.

                  Please send problems for Vim itself to me. The FreeBSD port shouldn't contain
                  any patches for the code, since Vim compiles fine without.

                  --
                  FATHER: You killed eight wedding guests in all!
                  LAUNCELOT: Er, Well ... the thing is ... I thought your son was a lady.
                  FATHER: I can understand that.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                  /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                  \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
                Your message has been successfully submitted and would be delivered to recipients shortly.