grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem


From: Ilya Bakulin
Subject: Re: GRUB2 on OpenBSD 5.3-amd64: linking problem
Date: Mon, 23 Sep 2013 17:59:49 +0200
User-agent: KMail/1.9.10 (enterprise35 20120322.0d8ab49a133482885a7a6ae00ec4472b1859206f)

Hi Vladimir,
So I'm preparing a OpenBSD port of GRUB2. I have chosen a revision 5152
for the initial version of the port.
Unfortunately, the build fails when using -Werror.
I suspect that the ports framework overrides some values that are usually 
guessed by ./configure, and this causes build to fail.

The build log are available here:
Build with -Werror:
http://dl.bakulin.de/openbsd/grub-build/make_werror.log

Build without -Werror: 
http://dl.bakulin.de/openbsd/grub-build/make_no_werror.log

Build using ./configure --disable-silent-rules LEX=/usr/local/bin/gflex, out 
of ports framework (in this case ./configure doesn't use any cached values):
http://dl.bakulin.de/openbsd/grub-build/make_standalone.log

I am not familiar with the GNU configure, but AFAIK the product of ./configure
is the set of config-*.h files. If it is right, there are two files for GRUB2,
config.h and config-util.h. Here is a diff between config-util.h generated 
during standalone and port build:

$ diff config-util.h_standalone  config-util.h_portbuild                        
                                                                                
                
1040c1040
< /* #undef HAVE_SYS_MOUNT_H */
---
> #define HAVE_SYS_MOUNT_H 1
1518c1518
< #define restrict __restrict
---
> #define restrict __restrict__

That is, HAVE_SYS_MOUNT_H is defined when building the port, and "restrict" is 
__restrict__.

Could you please help me to debug this error?

--
Ilya

On Wednesday 18 September 2013 13:49:38 Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> On 30.08.2013 19:33, Douglas Ray wrote:
> > calomel.org asserts that, as of OpenBSD 5.1, all their random devices
> > use the arc4 library;  /dev/urandom now gives as good as /dev/arandom.
>
> This is good enough. We are not crypto society which goes into security
> holes in other software. Also impact of bad random is minor in GRUB
> case. If X is considered the right to get random on given OS then it's ok.

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]