BSD

NAVIGATION
CATEGORIES
REFERRENCE
LINKS
  • stuck on "upgrading from 3.7 to 3.8 - Exception handling flag day"

    7 answers - 1334 bytes - related search similar search Add To My Delicious Add To My Stumble Upon Add To My Google Mark Add To My Facebook Add To My Digg Add To My Reddit

    If you get stuck doing an upgrade build, please do a standard upgrade
    or reinstall.
    We have never promised that such builds will work perfectly, nor can we
    dedicate 3-4 developers full-time to making sure they do. Which is
    pretty much what it would take.

    >From

    I see that I need to issue the following:
    # cd /usr/src/gnu/lib/libstdc++
    # make -f Makefile.bsd-wrapper cleandir
    # make -f Makefile.bsd-wrapper obj
    # make -f Makefile.bsd-wrapper
    # make -f Makefile.bsd-wrapper install
    I have updated my gcc (3 times now :). When I get to the next-to-last
    step (before install), my build aborts with:
    c++ -pipe -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -ffunction-sections -fdata-sections -c / -fPIC -DPIC -o eh_alloc.o
    In file included from /,
    from /
    / bits/os_defines.h: No such file or directory
    Error code 1
    Stop in /
    Error code 1
    Stop in /usr/src/gnu/lib/libstdc++/obj (line 304 of Makefile).
    Error code 1
    Stop in /usr/src/gnu/lib/libstdc++/obj (line 419 of Makefile).
    Error code 1
    Stop in /usr/src/gnu/lib/libstdc++ (line 22 of /).
    Help! What am I doing wrong? It's holding up a "cd /usr/src && make build"
    as well. Do I dare issue "make -k" to get past that?
  • No.1 | | 871 bytes | |

    "Theo" == Theo de Raadt <deraadt (AT) cvs (DOT) openbsd.orgwrites:

    TheoIf you get stuck doing an upgrade build, please do a standard upgrade
    Theoor reinstall.

    TheoWe have never promised that such builds will work perfectly, nor can we
    Theodedicate 3-4 developers full-time to making sure they do. Which is
    Theopretty much what it would take.

    I understand that. However, I'm hoping that someone else reading this
    mailing list will have tried the paragraph given in the FAQ, and either
    succeeded with a workaround, or discovered the futility as well.

    I'm upgrading a remote box, so a "standard upgrade" is not an option,
    nor is a reinstall. There was no warning in the FAQ that the
    information was definitely broken. It must have worked for *someone*
    or it wouldn't have been put in the FAQ, I presume.
  • No.2 | | 434 bytes | |

    16 Dec 2005 14:41:38 -0800, Randal L. Schwartz <merlyn (AT) stonehenge (DOT) comwrote:

    I'm upgrading a remote box, so a "standard upgrade" is not an option,
    nor is a reinstall. There was no warning in the FAQ that the
    information was definitely broken. It must have worked for *someone*
    or it wouldn't have been put in the FAQ, I presume.

    what is wrong with tar -C / -zxvpf base38.tgz ?
  • No.3 | | 1823 bytes | |

    16 Dec 2005 14:41:38 -0800, Randal L. Schwartz <merlyn (AT) stonehenge (DOT) comwrote:
    "Theo" == Theo de Raadt <deraadt (AT) cvs (DOT) openbsd.orgwrites:

    TheoIf you get stuck doing an upgrade build, please do a standard upgrade
    Theoor reinstall.

    TheoWe have never promised that such builds will work perfectly, nor can we
    Theodedicate 3-4 developers full-time to making sure they do. Which is
    Theopretty much what it would take.

    I understand that. However, I'm hoping that someone else reading this
    mailing list will have tried the paragraph given in the FAQ, and either
    succeeded with a workaround, or discovered the futility as well.

    I'm upgrading a remote box, so a "standard upgrade" is not an option,
    nor is a reinstall. There was no warning in the FAQ that the
    information was definitely broken. It must have worked for *someone*
    or it wouldn't have been put in the FAQ, I presume.

    First off, I fail to see how extracting the install sets via ssh can't
    be done, as that's mentioned in the FAQ as one upgrade method. Second,
    the source upgrade stuff has worked for people in the past, but they
    usually know enough about the system to actually fix something if it
    breaks. A source upgrade probably has less of a chance of working as
    extracting the install sets via ssh as mentioned in the FAQ, so you're
    running a risk either way. My suggestion, get the box shipped back to
    you or ship out a new hard drive with the new install on it, and all
    the other data copied over. Since BSD is compiled to work on all
    i386 boxes, it shouldn't really matter which box you install it on, as
    long as you properly set the network config how it should be on the
    remote box.

    Jason
  • No.4 | | 575 bytes | |

    Dec 16, 2005, at 6:00 PM, Jason Crawford wrote:
    First off, I fail to see how extracting the install sets via ssh can't
    be done, as that's mentioned in the FAQ as one upgrade method.

    Upgrading via the install sets remotely works absolutely fine. I do
    it every six months on a couple dozen boxes scattered all over the
    place. It takes *maybe* ten minutes, and perhaps another ten to get
    the box's services back up.

    If Randall is having issues reading the (very clear) upgrade FAQ, my
    services are available for a nominal fee. ;-)
  • No.5 | | 690 bytes | |

    Hello!

    Fri, Dec 16, 2005 at 03:46:21PM -0700, Theo de Raadt wrote:
    >[]


    >What do you suggest? Because the only other alternative is to DELETE
    >the upgrade faq.


    Please don't. There're people who use the upgrade FAQ as it's intended
    (i.e. one may try it out, but one is on one's own, if things fail and
    one can't fix it, use binaries to get close to the revision(s) one wants
    to compile, i.e. the release binaries to get to stable, the latest
    snapshot to possibly get to current).

    >[]


    Kind regards,

    Hannah.
  • No.6 | | 1312 bytes | |

    "Hannah" == Hannah Schroeter <hannah (AT) schlund (DOT) dewrites:

    HannahPlease don't. There're people who use the upgrade FAQ as it's intended
    Hannah(i.e. one may try it out, but one is on one's own, if things fail and
    Hannahone can't fix it, use binaries to get close to the revision(s) one wants
    Hannahto compile, i.e. the release binaries to get to stable, the latest
    Hannahsnapshot to possibly get to current).

    And it successfully worked for the past five upgrades. That's why I
    was surprised when it didn't work *immediately* this time.

    Now that I know that using source to leap from one release to the next
    is *less* supported than a binary leap, I understand the risk better.

    Prior to that, I had equated the risk.

    So thank you all. I learned, but I also spent the time to learn.

    By the way, I was thinking through my workaround, and have a
    hypothesis that binary cross-platform builds may actually be
    tainted because that part of the build step must have been looking
    at *installed* include files, not just in-build-area include files,
    which is why it more or less "works" now, after the first bootstrap
    installation.

    Thus, there may be a bug there. Might deserve some investigation.
  • No.7 | | 501 bytes | |

    17 Dec 2005 08:51:01 -0800, Randal L. Schwartz <merlyn (AT) stonehenge (DOT) comwrote:
    By the way, I was thinking through my workaround, and have a
    hypothesis that binary cross-platform builds may actually be
    tainted because that part of the build step must have been looking
    at *installed* include files, not just in-build-area include files,
    which is why it more or less "works" now, after the first bootstrap
    installation.

    which aren't supported either.

Re: stuck on "upgrading from 3.7 to 3.8 - Exception handling flag day"


max 4000 letters.
Your nickname that display:
In order to stop the spam: 4 + 3 =
QUESTION ON "BSD"

EMSDN.COM