DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Installation and Upgrading

OpenBSD Installation and Upgrading Installing and upgrading OpenBSD.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 10th May 2012
comet--berkeley comet--berkeley is offline
Shell Scout
 
Join Date: Apr 2009
Posts: 90
Thanked 1 Time in 1 Post
Default *** Error code 1 building OpenBSD 5.1-stable from source

After successfully installing 5.1, I had a lot of trouble building 5.1-stable from source.

I built the kernel ok in /usr/sys and rebooted fine.

But when I tried a "make build" of userland in /usr/src then this error
appeared:
Quote:
cc -c -O2 -pipe -I. -I/usr/src/gnu/usr.bin/binutils/gdb -I/usr/src/gnu/usr.bin/binutils/gdb/config -DLOCALEDIR="\"/usr/share/locale\"" -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/binutils/gdb/../include/opcode -I../bfd -I/usr/src/gnu/usr.bin/binutils/gdb/../bfd -I/usr/src/gnu/usr.bin/binutils/gdb/../include -I../intl -I/usr/src/gnu/usr.bin/binutils/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized -Wformat-nonliteral -Wunused-label -Wunused-function /usr/src/gnu/usr.bin/binutils/gdb/i386obsd-tdep.c
/usr/src/gnu/usr.bin/binutils/gdb/observer.sh h /usr/src/gnu/usr.bin/binutils/gdb/doc/observer.texi observer.h
*** Error code 1

Stop in /usr/src/gnu/usr.bin/binutils/obj/gdb (line 1335 of Makefile).
*** Error code 1

Stop in /usr/src/gnu/usr.bin/binutils/obj (line 21479 of Makefile).
*** Error code 1

Stop in /usr/src/gnu/usr.bin/binutils (line 72 of /usr/src/gnu/usr.bin/binutils/Makefile.bsd-wrapper).
*** Error code 1

Stop in /usr/src/gnu/usr.bin (line 48 of /usr/share/mk/bsd.subdir.mk).
*** Error code 1

Stop in /usr/src/gnu (line 48 of /usr/share/mk/bsd.subdir.mk).
*** Error code 1

Stop in /usr/src (line 48 of /usr/share/mk/bsd.subdir.mk).
*** Error code 1

Stop in /usr/src (line 80 of Makefile).

After trying different things for several days, I came upon this thread in gmane which fixed the problem:

http://permalink.gmane.org/gmane.os.openbsd.tech/16531

I had to edit the /cvs/src/gnu/usr.bin/binutils/gdb/Makefile.in

and change the execution of observer.sh to have "sh -e" in front:

observer.h: observer.sh doc/observer.texi
- ${srcdir}/observer.sh h ${srcdir}/doc/observer.texi observer.h
+ sh -e ${srcdir}/observer.sh h ${srcdir}/doc/observer.texi observer.h

observer.inc: observer.sh doc/observer.texi
- ${srcdir}/observer.sh inc ${srcdir}/doc/observer.texi observer.inc
+ sh -e ${srcdir}/observer.sh inc ${srcdir}/doc/observer.texi observer.inc
Reply With Quote
  #2   (View Single Post)  
Old 10th May 2012
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 2,883
Thanked 190 Times in 160 Posts
Default

Quote:
Originally Posted by comet--berkeley View Post
I built the kernel ok in /usr/sys and rebooted fine.
/usr/src/sys
Quote:
But when I tried a "make build" of userland in /usr/src then this error
appeared:
  • Is the time in the new kernel set correctly?
  • Was DESTDIR set before issuing make distrib-dirs?
The instructions in Section 5.3.5 of the FAQ must be followed exactly. Unlike building the kernel, userland must be built as root.
Reply With Quote
  #3   (View Single Post)  
Old 10th May 2012
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,686
Thanked 214 Times in 189 Posts
Default

The rules for -stable patch commits prohibit library or tool chain changes of any kind. Therefore, there is an extremely high likelihood that a -stable build failure is due to an operational error of some kind. Hardware problems (cpu heat stress, RAM errors) are another possibility, but is not applicable in the case described in this thread.

Ocicat described several common problems -- another is sometimes the wrong source tree. You can check to ensure your /usr/src tree is indeed -stable. Review any .../CVS/Tag file in /usr/src to be sure the cvs(1) working directory is using source tagged with OPENBSD_5_1, the tag for 5.1-stable.

---
Edited to add: I'm not stating that "incorrect source code tree" is your problem, merely pointing out that in the general case this is something to double check if and when a build problem arises.

Last edited by jggimi; 10th May 2012 at 01:36 PM.
Reply With Quote
  #4   (View Single Post)  
Old 12th May 2012
comet--berkeley comet--berkeley is offline
Shell Scout
 
Join Date: Apr 2009
Posts: 90
Thanked 1 Time in 1 Post
Default

Thank you ocicat and jggimi for the responses.

Quote:
Originally Posted by ocicat View Post
/usr/src/sys
  • Is the time in the new kernel set correctly?
  • Was DESTDIR set before issuing make distrib-dirs?
The instructions in Section 5.3.5 of the
FAQ must be followed exactly. Unlike building the kernel, userland [I]must[/I
] be built as root.
I believe that the time was set correctly. What would "time in the new kernel" set incorrectly look like?

The DESTDIR is a possible issue. Before building 5.1-stable, I successfully built 5.0-stable and left two exports in the root .profile from building the 5.0-stable distribution:

export DESTDIR=/usr/dest
export RELEASEDIR=/usr/rel

I had to remove these before the 5.1 "make build" would allow the world to be built but they were probably in place during the "make distrib-dirs"

cd /usr/src/etc && env DESTDIR=/ make distrib-dirs

Doesn't the env DESTDIR override the previous export DESTDIR?

I did not really have any problems with the "make build" except the observer.sh script.

The observer.sh shell script would not execute without an explicit "sh" in front of it. After the "make build" failed I looked at the execute permissions on the script and they appeared to be 755.

The build ran for over two hours making everything ok up to the point where the Gnu gdb debugger was built and the observer.sh script was part of the gdb build.

Quote:
Originally Posted by jggimi View Post
The rules for -stable patch commits prohibit library or tool chain changes of any kind. Therefore, there is an extremely high likelihood that a -stable build failure is due to an operational error of some kind. Hardware problems (cpu heat stress, RAM errors) are another possibility, but is not applicable in the case described in this thread.

Ocicat described several common problems -- another is sometimes the wrong source tree. You can check to ensure your /usr/src tree is indeed -stable. Review any .../CVS/Tag file in /usr/src to be sure the cvs(1) working directory is using source tagged with OPENBSD_5_1, the tag for 5.1-stable.

---
Edited to add: I'm not stating that "incorrect source code tree" is your problem, merely pointing out that in the general case this is something to double check if and when a build problem arises.
I checked the source tree and did not see anything wrong. I downloaded the source from an ftp site and checked the file sizes from another ftp site.

Is there a checksum somewhere for the src.tar.gz, and sys.tar.gz files?

In the recent past I successfully built 5.0-stable using the patch method.

For 5.1-stable I tried both the patch method and the CVS method and both failed with the observer.sh script.

The usual cause of this kind of problem is a lack of execute permissions on the file.

But why only the observer.sh script? And why did the build work fine for two hours before it got to the Gnu gdb part and the observer.sh script?

And why did not any other scripts fail? I changed the execution of observer.sh to "sh -e observer.sh" and the whole build worked fine.
Reply With Quote
  #5   (View Single Post)  
Old 12th May 2012
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 2,883
Thanked 190 Times in 160 Posts
Default

Quote:
Originally Posted by comet--berkeley View Post
I believe that the time was set correctly. What would "time in the new kernel" set incorrectly look like?
The fundamental problem is a mismatch between:
  • the current time understood by the BIOS.
  • the current time understood by the kernel.
...which is discussed in Section 8.25 of the FAQ. If the newly installed kernel is not tracking the correct current time, files freshly downloaded under the previous kernel may have timestamps sometime in the future relative to the new kernel's incorrect current time. This will wreck havoc when building with make(1). I have had this situation before when building -current, & the userland build usually broke very late in the userland build somewhere when building Apache-related binaries. I haven't made this mistake for awhile, so I don't know where breakage would happen today.
Quote:
...I successfully built 5.0-stable and left two exports in the root .profile from building the 5.0-stable distribution:
Don't make these values persist in ~/.profile. I have made this mistake before, & it will wreck havoc in very subtle ways if present when building ports. DESTDIR & RELEASEDIR should only be set when building userland, & never elsewhere. Once userland is finished building, make sure these variables are no longer set.
Reply With Quote
  #6   (View Single Post)  
Old 14th May 2012
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,686
Thanked 214 Times in 189 Posts
Default

I missed this question, and wanted to take a moment to answer it.
Quote:
Originally Posted by comet--berkeley View Post
Is there a checksum somewhere for the src.tar.gz, and sys.tar.gz files?
Not to my knowledge. However you need not use them if you do not wish to; their use merely reduces load on a CVS server (and bandwidth for you) on initial checkout of a -stable or -current working directory.

These tarballs are -release sources, converted from a CVS working directory into a standard file hierarchy via the cvs(1) export command. To use them, you would have unpacked these tarballs, and then converted the directory structure back into a CVS working directory with a cvs(1) checkout command. The process is described under FAQ 5.3.3 in "Pre-loading the tree" and in the AnonCVS FAQ under "Getting Started with Anonymous CVS".

Last edited by jggimi; 14th May 2012 at 05:14 PM. Reason: clarity
Reply With Quote
  #7   (View Single Post)  
Old 16th May 2012
comet--berkeley comet--berkeley is offline
Shell Scout
 
Join Date: Apr 2009
Posts: 90
Thanked 1 Time in 1 Post
Default

Thank you ocicat and jggimi.

Quote:
Originally Posted by ocicat View Post
.

Quote:
Originally Posted by comet--berkeley View Post
The DESTDIR is a possible issue. Before building 5.1-stable, I successfully built 5.0-stable and left two exports in the root .profile from building the 5.0-stable distribution:

export DESTDIR=/usr/dest
export RELEASEDIR=/usr/rel
Don't make these values persist in ~/.profile. I have made this mistake before, & it will wreck havoc in very subtle ways if present when building ports. DESTDIR & RELEASEDIR should only be set when building userland, & never elsewhere. Once userland is finished building, make sure these variables are no longer set.
I believe that the DESTDIR and/or RELEASEDIR environment variables are the issue.

As a new step in my userland build process I now do this:

unset DESTDIR
unset RELEASEDIR

And I am now able to build userland without modifying any makefiles.

(I just built the kernel and userland from sources with a manual patch.)

This bug has caught others in the past as well:

http://www.monkey.org/openbsd/archiv.../msg00346.html

http://www.mail-archive.com/misc@ope.../msg54292.html

And Amaud who created a work-around:

http://permalink.gmane.org/gmane.os.openbsd.tech/16531

After searching Google, Amaud's fix worked for me.

But perhaps the 'unset DESTDIR' and 'unset RELEASEDIR' commands should be put into
the FAQ?

Or even better yet put into the userland 'make build' process itself?

Last edited by comet--berkeley; 17th May 2012 at 05:53 AM. Reason: spelling
Reply With Quote
  #8   (View Single Post)  
Old 16th May 2012
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,686
Thanked 214 Times in 189 Posts
Default

The unset is articulated in release(8).

To propose any FAQ change, I recommend you:
  1. Checkout the www repository into a local working directory.
  2. Devise your change to the applicable .html file.
  3. Create a unified diff of your change.
  4. Subscribe to the www@ mailing list.
  5. Post your proposed patch to the www@ mailing list, requesting consideration.

Last edited by jggimi; 16th May 2012 at 03:33 PM. Reason: typo
Reply With Quote
  #9   (View Single Post)  
Old 17th May 2012
comet--berkeley comet--berkeley is offline
Shell Scout
 
Join Date: Apr 2009
Posts: 90
Thanked 1 Time in 1 Post
Default

Quote:
Originally Posted by jggimi View Post
The unset is articulated in release(8).
I had not seen the release(8) man page before.

It clearly shows doing the unset DESTDIR RELEASEDIR immediately after the make release

And it probably is best not to set DESTDIR and RELEASEDIR in the .profile as ocicat says:

Quote:
Originally Posted by ocicat View Post
Don't make these values persist in ~/.profile. I have made this mistake before, & it will wreck havoc in very subtle ways if present when building ports. DESTDIR & RELEASEDIR should only be set when building userland, & never elsewhere. Once userland is finished building, make sure these variables are no longer set.
If I leave them set in the .profile then I will need to unset them every time I build ports as well as every time I build userland... too risky.

Maybe the FAQ needs to show the unset after the make release and explain that leaving them set can mess up the port builds as well.

Thanks again guys.

Last edited by comet--berkeley; 17th May 2012 at 06:23 AM. Reason: spelling
Reply With Quote
Old 17th May 2012
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,686
Thanked 214 Times in 189 Posts
Default

Quote:
If I leave them set in the .profile then I will need to unset them every time I build ports as well as every time I build userland...
My practice is to use shell scripts for build steps. Environment variables exported within a script are useable only within the script and its children, so I set DESTDIR and RELEASEDIR values within my personal "build-release" and "build-xrelease" scripts, and never need to unset them.
Reply With Quote
Old 19th May 2012
comet--berkeley comet--berkeley is offline
Shell Scout
 
Join Date: Apr 2009
Posts: 90
Thanked 1 Time in 1 Post
Default

Quote:
Originally Posted by jggimi View Post
The unset is articulated in release(8).

To propose any FAQ change, I recommend you:
  1. Checkout the www repository into a local working directory.
  2. Devise your change to the applicable .html file.
  3. Create a unified diff of your change.
  4. Subscribe to the www@ mailing list.
  5. Post your proposed patch to the www@ mailing list, requesting consideration.
I did exactly the above. I checked out the www source tree using cvsync and then cvs.
Made changes to faq/faq5.html and used cvs diff -u to create a unified diff.
Reply With Quote
Old 19th May 2012
comet--berkeley comet--berkeley is offline
Shell Scout
 
Join Date: Apr 2009
Posts: 90
Thanked 1 Time in 1 Post
Default

Quote:
Originally Posted by jggimi View Post
I missed this question, and wanted to take a moment to answer it.Not to my knowledge. However you need not use them if you do not wish to; their use merely reduces load on a CVS server (and bandwidth for you) on initial checkout of a -stable or -current working directory.

These tarballs are -release sources, converted from a CVS working directory into a standard file hierarchy via the cvs(1) export command. To use them, you would have unpacked these tarballs, and then converted the directory structure back into a CVS working directory with a cvs(1) checkout command. The process is described under FAQ 5.3.3 in "Pre-loading the tree" and in the AnonCVS FAQ under "Getting Started with Anonymous CVS".
The stable document mentions using the source and manually patching it when it says:

Stick with our latest release and apply the patches by hand.

http://www.openbsd.org/stable.html

That is what I have done in the past without having to use CVS.

In that case it would be nice to have a checksum for both the source tarballs and for the patches.
Reply With Quote
Old 19th May 2012
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,686
Thanked 214 Times in 189 Posts
Default

There are three bullets, and that is one of your three choices for maintenance. That choice is often refereed to as "-release plus errata" to distinguish it from -stable, which is the patch branch. There are stable patches which are committed, from time to time, without being posted as errata on the project website. There may be differences, then, ibetween the two options for maintenance.

Nice job on the Email to www@.

Last edited by jggimi; 19th May 2012 at 02:20 AM. Reason: typo, missing sentence
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
PHP.net breach: Concern over safety of source code J65nko News 2 24th March 2011 09:57 AM
explore source code for installed program bsdnewbie999 OpenBSD General 1 23rd February 2009 06:13 AM
Trying to compile GLUT source code on freebsd. welkin Programming 0 11th January 2009 03:15 PM
Error building world 6.3 -> 6.4 chavez243 FreeBSD Installation and Upgrading 1 7th January 2009 02:31 PM
Source code for ed? matt FreeBSD Ports and Packages 1 21st October 2008 08:18 PM


All times are GMT. The time now is 01:55 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick