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

sigaltstack

Expand Messages
  • Johannes Zellner
    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
    Message 1 of 12 , Nov 1, 2000
    • 0 Attachment
      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

      --
      Johannes
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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.