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

Re: sigaltstack

Expand Messages
  • Bram Moolenaar
    ... Strange. I m also using FreeBSD 4.0 and have no problems. Also, sigaltstack() is called from init_signal_stack(), not from the functions you mention.
    Message 1 of 12 , Nov 2, 2000
    • 0 Attachment
      Johannes Zellner wrote:

      > I just tried to compile 6.0k on FreeBSD (4.0)
      >
      > objects/os_unix.o: In function `mch_didjmp':
      > objects/os_unix.o(.text+0x21ef): undefined reference to `sigaltstack'
      > objects/os_unix.o: In function `mch_init':
      > objects/os_unix.o(.text+0x278a): undefined reference to `sigaltstack'
      > *** Error code 1

      Strange. I'm also using FreeBSD 4.0 and have no problems.

      Also, sigaltstack() is called from init_signal_stack(), not from the functions
      you mention.

      Confused... Can you give more information?

      --
      login: yes
      password: I don't know, please tell me
      password is incorrect
      login: yes
      password: incorrect

      /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
      \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
    • Johannes Zellner
      ... src/auto/config.h: #define HAVE_SIGALTSTACK 1 /* #undef HAVE_SIGSTACK */ /* #undef HAVE_SIGSET */ #define HAVE_SIGACTION 1 #define HAVE_SIGVEC 1 .... maybe
      Message 2 of 12 , Nov 3, 2000
      • 0 Attachment
        On Thu, Nov 02, 2000 at 10:43:01AM +0100, Bram Moolenaar wrote:
        >
        > Johannes Zellner wrote:
        >
        > > I just tried to compile 6.0k on FreeBSD (4.0)
        > >
        > > objects/os_unix.o: In function `mch_didjmp':
        > > objects/os_unix.o(.text+0x21ef): undefined reference to `sigaltstack'
        > > objects/os_unix.o: In function `mch_init':
        > > objects/os_unix.o(.text+0x278a): undefined reference to `sigaltstack'
        > > *** Error code 1
        >
        > Strange. I'm also using FreeBSD 4.0 and have no problems.
        >
        > Also, sigaltstack() is called from init_signal_stack(), not from the functions
        > you mention.
        >
        > Confused... Can you give more information?

        src/auto/config.h:

        #define HAVE_SIGALTSTACK 1
        /* #undef HAVE_SIGSTACK */
        /* #undef HAVE_SIGSET */
        #define HAVE_SIGACTION 1
        #define HAVE_SIGVEC 1
        ....

        maybe you can compare that to what you get on your system ?
        If I look into /usr/include/signal.h:

        #ifndef _POSIX_SOURCE
        ...
        int sigaltstack __P((const stack_t *, stack_t *));

        hm. maybe _POSIX_SOURCE is defined ? -- But I get the error
        when linking not when compiling, so the prototype is there,
        but the function is not found while linking.


        I'm linking with

        gcc -o vim [OBJECTS ...] -lncurses -lposix1e -lxpg4 \
        /usr/local/lib/python1.5/config/libpython1.5.a \
        -lmytinfo -lreadline -lm -lcrypt -lxpg4 -lm -pthread

        (building w/o X).

        If I manuall remove

        // #define HAVE_SIGALTSTACK 1

        then it compiles. Strange.

        --
        Johannes
      • Bram Moolenaar
        ... It s the same. ... This shouldn t matter. It s only a prototype to avoid warnings while compiling. ... Since configure has set HAVE_SIGALTSTACK, it must
        Message 3 of 12 , Nov 4, 2000
        • 0 Attachment
          Johannes Zellner wrote:

          > > > I just tried to compile 6.0k on FreeBSD (4.0)
          > > >
          > > > objects/os_unix.o: In function `mch_didjmp':
          > > > objects/os_unix.o(.text+0x21ef): undefined reference to `sigaltstack'
          > > > objects/os_unix.o: In function `mch_init':
          > > > objects/os_unix.o(.text+0x278a): undefined reference to `sigaltstack'
          > > > *** Error code 1
          > >
          > > Strange. I'm also using FreeBSD 4.0 and have no problems.
          > >
          > > Also, sigaltstack() is called from init_signal_stack(), not from the
          > > functions you mention.
          > >
          > > Confused... Can you give more information?
          >
          > src/auto/config.h:
          >
          > #define HAVE_SIGALTSTACK 1
          > /* #undef HAVE_SIGSTACK */
          > /* #undef HAVE_SIGSET */
          > #define HAVE_SIGACTION 1
          > #define HAVE_SIGVEC 1
          > ....
          >
          > maybe you can compare that to what you get on your system ?

          It's the same.

          > If I look into /usr/include/signal.h:
          >
          > #ifndef _POSIX_SOURCE
          > ...
          > int sigaltstack __P((const stack_t *, stack_t *));
          >
          > hm. maybe _POSIX_SOURCE is defined ? -- But I get the error
          > when linking not when compiling, so the prototype is there,
          > but the function is not found while linking.

          This shouldn't matter. It's only a prototype to avoid warnings while
          compiling.

          > I'm linking with
          >
          > gcc -o vim [OBJECTS ...] -lncurses -lposix1e -lxpg4 \
          > /usr/local/lib/python1.5/config/libpython1.5.a \
          > -lmytinfo -lreadline -lm -lcrypt -lxpg4 -lm -pthread
          >
          > (building w/o X).
          >
          > If I manuall remove
          >
          > // #define HAVE_SIGALTSTACK 1
          >
          > then it compiles. Strange.

          Since configure has set HAVE_SIGALTSTACK, it must be on your system. I can't
          guess why configure could find sigaltstack() and the linker could not.
          Normally I would expect that you need to add some library, but since you're on
          FreeBSD 4.0 it should be in libc.

          One desparate idea: Perhaps you have an outdated os_unix.o file?

          --
          hundred-and-one symptoms of being an internet addict:
          34. You laugh at people with 14400 baud modems.

          /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
          \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
        • Matthew Hawkins
          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
          Message 4 of 12 , Nov 30, 2000
          • 0 Attachment
            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 ;).

            --
            Matt
          • 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 5 of 12 , Nov 30, 2000
            • 0 Attachment
              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 6 of 12 , Dec 1, 2000
              • 0 Attachment
                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 7 of 12 , Dec 1, 2000
                • 0 Attachment
                  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 8 of 12 , Dec 1, 2000
                  • 0 Attachment
                    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 9 of 12 , Dec 1, 2000
                    • 0 Attachment
                      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 10 of 12 , Dec 2, 2000
                      • 0 Attachment
                        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 11 of 12 , Dec 3, 2000
                        • 0 Attachment
                          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.