When building with --target=arm-linux-gnu --with-platform=coreboot
a linking error occurs caused by multiple definitions of the
ps2_state variable.
Mark them as static since they aren't used outside their compilation unit.
Signed-off-by: Javier Martinez Canillas
---
grub-core/term/arm/c
Running from address 0 is plausible at least in principal. Use the maximum
possible address as a sentinal instead.
Signed-off-by: Ian Campbell
---
util/grub-mkimagexx.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/util/grub-mkimagexx.c b/util/grub-mkimagexx.c
inde
On Tue, Nov 26, 2013 at 11:53 AM, Beeblebrox wrote:
> OK, I'll try it. But I need clarification:
>
> * Should I copy the repo and do a git rollback on the copy?
Just setup separate tree to perform build. The actual state does not
really matter; you can use current master, ignore doc build error f
OK, I'll try it. But I need clarification:
* Should I copy the repo and do a git rollback on the copy?
* Easier to copy only grub/docs to another folder, but how do I start
the build then? The Makefile in grub/docs will fail just as when run
from top-level.
>> just copy grub.texi over
>From my cu
On Tue, Nov 26, 2013 at 11:31 AM, Beeblebrox wrote:
> It's OK, I don't need it really. Unless you need me to test and get
> back to you with results.
Would be nice; as new release is planned in not so distant future, we
should try to iron out problems.
___
> Did earlier versions grub.texi compiled?
Yes, earlier versions of grub.texi did compile.
> Setup build tree outside of git checkout and just copy
> grub.texi over; it is self contained.
It's OK, I don't need it really. Unless you need me to test and get
back to you with results.
___
On Tue, Nov 26, 2013 at 11:19 AM, Beeblebrox wrote:
> Still have to manually clean out the "docs" references in Makefile however.
>
Did earlier versions grub.texi compiled? In this case you could try to
bisect it. Setup build tree outside of git checkout and just copy
grub.texi over; it is self
>> Or just update to current trunk, I committed this patch.
Updated to trunk, it all works & gets compiled.
Still have to manually clean out the "docs" references in Makefile however.
Thanks for the swift work.
___
Grub-devel mailing list
Grub-devel@gn
В Mon, 25 Nov 2013 19:19:00 +0100
Vladimir 'φ-coder/phcoder' Serbinenko пишет:
> On 25.11.2013 19:13, Andrey Borzenkov wrote:
> > Similar to check for target linking format, also check for efiemu64
> > instead of hardcoding -melf_x86_64. This fixes compilation on *BS
On 25.11.2013 19:13, Andrey Borzenkov wrote:
> Similar to check for target linking format, also check for efiemu64
> instead of hardcoding -melf_x86_64. This fixes compilation on *BSD
> variants. We cannot easily reuse main target check because platforms
> are different (main target i
Similar to check for target linking format, also check for efiemu64
instead of hardcoding -melf_x86_64. This fixes compilation on *BSD
variants. We cannot easily reuse main target check because platforms
are different (main target is 32 bit and efiemu64 - 64 bit).
This commit adds
On 25.11.2013 18:42, Andrey Borzenkov wrote:
> В Mon, 25 Nov 2013 05:22:58 +0100
> Vladimir 'φ-coder/phcoder' Serbinenko пишет:
>
>>> + CFLAGS="-m64 -nostdlib -O2 -mcmodel=large -mno-red-zone"
>>> + LDFLAGS="-m64 -Wl,$format -nostdlib"
>> You need -static as otherwise on Apple systems i
В Mon, 25 Nov 2013 05:22:58 +0100
Vladimir 'φ-coder/phcoder' Serbinenko пишет:
> > + CFLAGS="-m64 -nostdlib -O2 -mcmodel=large -mno-red-zone"
> > + LDFLAGS="-m64 -Wl,$format -nostdlib"
> You need -static as otherwise on Apple systems it will try to pull in
> the dynamic linker which we
On 24.11.2013 18:21, Andrey Borzenkov wrote:
> Similar to check for target linking format, also check for efiemu64
> instead of hardcoding -melf_x86_64. This fixes compilation on *BSD
> variants. We cannot easily reuse main target check because platforms
> are different (main target i
On 24.11.2013 18:21, Andrey Borzenkov wrote:
> +for format in -melf_x86_64 -melf_x86_64_fbsd -melf_x86_64_obsd
> -melf_x86_64_haiku -mx86_64pe -arch,x86_64; do
Remove x86_64pe. We skip it in first check as well since we have no
converter for 64-bit windows binaries and the format is name i386p
Similar to check for target linking format, also check for efiemu64
instead of hardcoding -melf_x86_64. This fixes compilation on *BSD
variants. We cannot easily reuse main target check because platforms
are different (main target is 32 bit and efiemu64 - 64 bit).
This commit adds
On Monday 23 September 2013 18:16:15 Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 23.09.2013 17:59, Ilya Bakulin wrote:
> > Hi Vladimir,
> > So I'm preparing a OpenBSD port of GRUB2. I have chosen a revision 5152
> > for the initial version of the port.
>
> I already did couple revisions ago.
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 fa
On 23.09.2013 17:59, Ilya Bakulin wrote:
> Hi Vladimir,
> So I'm preparing a OpenBSD port of GRUB2. I have chosen a revision 5152
> for the initial version of the port.
I already did couple revisions ago. After that I made further
simplifications to multi-OS mess and it's possible that there is min
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
On 23/08/13 7:31 PM, Vladimir '?-coder/phcoder' Serbinenko wrote:
On 23.08.2013 11:26, Ilya Bakulin wrote:
On Thursday 22 August 2013 20:16:48 Vladimir '?-coder/phcoder' Serbinenko
wrote:
On 21.08.2013 21:06, Vladimir '?-coder/phcoder' Serbinenko wrote:
Based on your work, current WIP patch. I
On Friday 23 August 2013 11:31:06 Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > There is a warning about random generator not being secure in
> > util/grub-mkpasswd-pbkdf2.c, which may be supressed by adding "&& !
> > defined (__OpenBSD__)" to the defines list.
>
> To do this we need a confirmat
On 23.08.2013 11:26, Ilya Bakulin wrote:
> On Thursday 22 August 2013 20:16:48 Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
>> On 21.08.2013 21:06, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>> Based on your work, current WIP patch. I've committed some parts of your
>>> patch as well as my ow
On 16.08.2013 16:41, Grégoire Sutre wrote:
> On 08/16/2013 04:33 PM, Ilya Bakulin wrote:
>
>> So the types "double" and "float" are not recognized.
>>
>> Could you please help me to debug this?
>
> I get the exact same problem on NetBSD. A simple (temporary)
> work-around is to remove the flags:
On 08/16/2013 04:33 PM, Ilya Bakulin wrote:
So the types "double" and "float" are not recognized.
Could you please help me to debug this?
I get the exact same problem on NetBSD. A simple (temporary)
work-around is to remove the flags:
-Dfloat=__grub_poision -Ddouble=__grub_poision
Those ar
Hi Vladimir,
so I'm trying the latest version from BZR now. Running ./configure without
CFLAGS succeeds now, thanks!
On Wednesday 14 August 2013 18:28:45 Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> #ifdef __OpenBSD__
> #define mbstate_t grub_posix_mbstate_t
> #endif
Yes, this seems to help!
On 08/15/2013 05:00 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
This is not right fix. Many systems incorrectly define wchar_t as 16-bit
type whil GRUB needs at least 21 as we handle all unicode characters.
Please try:
=== modified file 'grub-core/lib/posix_wrap/wchar.h'
--- grub-core/lib/p
On 14.08.2013 15:49, Grégoire Sutre wrote:
On 08/14/2013 03:31 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
On 14.08.2013 15:09, Ilya Bakulin wrote:
./lib/posix_wrap/sys/types.h:25: error: conflicting types for 'size_t'
/usr/include/stddef.h:48: error: previous declaration of 'size_t' was
h
On 14.08.2013 17:16, Ilya Bakulin wrote:
If I move the "typedef mbstate .. mbstate_t" into '#if !defined(__OpenBSD__)',
then the code uses the version from stddef.h, which lacks "code" and "count"
fields. It is defined as follows:
Try:
#ifdef __OpenBSD__
#define mbstate_t grub_posix_mbstate_t
#e
Hi,
On Wednesday 14 August 2013 15:49:03 Grégoire Sutre wrote:
> On 08/14/2013 03:31 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > You need to modify following:
> > #ifndef __APPLE__
> > typedef grub_size_t size_t;
> > #else
> > #include
> > #endif
> > to
> > #if !defined (__APPLE__) && !d
On 08/14/2013 03:31 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
On 14.08.2013 15:09, Ilya Bakulin wrote:
./lib/posix_wrap/sys/types.h:25: error: conflicting types for 'size_t'
/usr/include/stddef.h:48: error: previous declaration of 'size_t' was
here
gmake[3]: *** [fs/squash4_module-squash4
On 14.08.2013 15:09, Ilya Bakulin wrote:
./lib/posix_wrap/sys/types.h:25: error: conflicting types for 'size_t'
/usr/include/stddef.h:48: error: previous declaration of 'size_t' was here
gmake[3]: *** [fs/squash4_module-squash4.o] Error 1
You need to modify following:
#ifndef __APPLE__
typedef g
On Wednesday 14 August 2013 10:59:24 Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 13.08.2013 23:03, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > On 09.08.2013 15:37, Ilya Bakulin wrote:
> >> Could you please help me to solve the linking probl
On 14.08.2013 15:09, Ilya Bakulin wrote:
So for proper compilation I_have_ to pass -ftrampolines in both CFLAGS and
TARGET_CFLAGS.
Please use latest bzr version.
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/g
On 13.08.2013 23:03, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
On 09.08.2013 15:37, Ilya Bakulin wrote:
Could you please help me to solve the linking problem?
What else do you need from me?
Sounds like your gcc doesn't pass -m32 to linker. Try at configue stage
set TARGET_LDF
On Friday 25 July 2008 22:43:10 Robert Millan wrote:
> On Fri, Jul 25, 2008 at 08:18:27AM -0700, Colin D Bennett wrote:
> > On Thu, 24 Jul 2008 22:17:06 -0700 (PDT)
> >
> > Viswesh S <[EMAIL PROTECTED]> wrote:
> > > I have modified the conf/common.mk accordingly as shown below.
> >
> > GRUB develop
On Fri, Jul 25, 2008 at 08:18:27AM -0700, Colin D Bennett wrote:
> On Thu, 24 Jul 2008 22:17:06 -0700 (PDT)
> Viswesh S <[EMAIL PROTECTED]> wrote:
>
> > I have modified the conf/common.mk accordingly as shown below.
>
> GRUB developers,
>
> I think we should remove conf/*.mk from the Subversion
On Thu, 24 Jul 2008 22:17:06 -0700 (PDT)
Viswesh S <[EMAIL PROTECTED]> wrote:
> I have modified the conf/common.mk accordingly as shown below.
GRUB developers,
I think we should remove conf/*.mk from the Subversion repository. If
people are going to be developing on GRUB and checking out svn
br
gnu.org
> Sent: Friday, 25 July, 2008 7:31:28 PM
> Subject: Re: Linking
>
> On Fri, 25 Jul 2008 03:22:57 -0700 (PDT)
> Viswesh S <[EMAIL PROTECTED]> wrote:
>
> > The reason for hello to be put in a directory because it is a module
> > and not a simple command.Unde
-devel@gnu.org
Sent: Friday, 25 July, 2008 7:31:28 PM
Subject: Re: Linking
On Fri, 25 Jul 2008 03:22:57 -0700 (PDT)
Viswesh S <[EMAIL PROTECTED]> wrote:
> The reason for hello to be put in a directory because it is a module
> and not a simple command.Understood myself
Actually, no. E
pment of GRUB 2
> Sent: Friday, 25 July, 2008 3:44:48 PM
> Subject: Re: Linking
>
>
> Hi,
>
> So if I add a module or add a new command,which are the files which I
> should modify in general and which all gets generated automatically.
> Is this somewhere documented ?
>
The reason for hello to be put in a directory because it is a module and not a
simple command.Understood myself
- Original Message
From: Viswesh S <[EMAIL PROTECTED]>
To: The development of GRUB 2
Sent: Friday, 25 July, 2008 3:44:48 PM
Subject: Re: Linking
Hi,
So if I
specific reason for this.
Viswesh
- Original Message
From: Pavel Roskin <[EMAIL PROTECTED]>
To: grub-devel@gnu.org
Sent: Friday, 25 July, 2008 11:59:21 AM
Subject: Re: Linking
Quoting Viswesh S <[EMAIL PROTECTED]>:
> Hi Pavel,
> Could you please attach the modified fi
Quoting Viswesh S <[EMAIL PROTECTED]>:
Hi Pavel,
Could you please attach the modified file ?
Viswesh
No, I'm just giving you an idea what you may be doing wrong.
--
Regards,
Pavel Roskin
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.
Hi Pavel,
Could you please attach the modified file ?
Viswesh
- Original Message
From: Pavel Roskin <[EMAIL PROTECTED]>
To: grub-devel@gnu.org
Sent: Friday, 25 July, 2008 11:05:49 AM
Subject: Re: Linking
Quoting Viswesh S <[EMAIL PROTECTED]>:
> I have modified the
Quoting Viswesh S <[EMAIL PROTECTED]>:
I have modified the conf/common.mk accordingly as shown below.
It's a generated file. Please modify conf/common.rmk instead and run
autogen.sh.
--
Regards,
Pavel Roskin
___
Grub-devel mailing list
Grub-de
Hi,
I am quite new to grub2 anf I find some issue in make of grub2
I modify the hello module by adding a new file a.c, with a function test() in
it.
I call the function test from hello entry point - grub_cmd_hello()
When I do a make, I get the error that
test in hello is not defined
make: *** [mo
Hollis Blanchard <[EMAIL PROTECTED]> writes:
Hi Hollis,
> Could somebody please confirm that x86 still builds and works with
> this patch? Thanks.
While compiling on my x86-64:
rm -f pre-_chain.o
gcc -melf_i386 -m32 -Wl,-r,-d -o pre-_chain.o
_chain_mod-loader_i386_pc_chainloader.o
/usr/bin/ld:
On Wednesday 19 April 2006 04:51, Hollis Blanchard wrote:
> Could somebody please confirm that x86 still builds and works with this
> patch? Thanks.
It was necessary to add -nostdlib like you did for ppc. Then it seems fine.
Okuji
___
Grub-devel maili
2006-04-18 Hollis Blanchard <[EMAIL PROTECTED]>
* Makefile.in (LDFLAGS): Add variable.
(LD): Remove variable.
* configure.ac: Add -m32 to LDFLAGS.
* genmk.rb (PModule#rule): Use $(CC) instead of $(LD).
* conf/powerpc-ieee1275.rmk (COMMON_LDFLAGS): Add var
50 matches
Mail list logo
