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

Re: sigaltstack

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.