On Monday, June 18, 2012 4:46:32 pm Mike Meyer wrote:
> On Mon, 18 Jun 2012 13:42:27 -0500
> Nathan Whitehorn wrote:
>
> > On 06/17/12 19:43, Mike Meyer wrote:
> > > Eric McCorkle wrote:
> > >> The -m32 flag seems to be the culprit; removing it fixes the problem.
> > >> This is why I was having
On Mon, 18 Jun 2012 13:42:27 -0500
Nathan Whitehorn wrote:
> On 06/17/12 19:43, Mike Meyer wrote:
> > Eric McCorkle wrote:
> >> The -m32 flag seems to be the culprit; removing it fixes the problem.
> >> This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE
> >> were wrong.
> >>
On 06/17/12 19:43, Mike Meyer wrote:
Eric McCorkle wrote:
The -m32 flag seems to be the culprit; removing it fixes the problem.
This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE
were wrong.
In any case, this is a pretty serious error, and someone should try to
reproduce
> This is a known issue, and had been around for a long time.
> You can't reliably build 32 bit binaries (what the -m32 flag specifies)
> on a 64 bit system. The header files (and possibly other things) are wrong.
People build 32 bit binaries on 64 bit systems all the time.
It is called cross-comp
On 6/17/12 8:43 PM, Mike Meyer wrote:
Eric McCorkle wrote:
The -m32 flag seems to be the culprit; removing it fixes the problem.
This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE
were wrong.
In any case, this is a pretty serious error, and someone should try to
reproduce
Eric McCorkle wrote:
>The -m32 flag seems to be the culprit; removing it fixes the problem.
>
>This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE
>were wrong.
>
>In any case, this is a pretty serious error, and someone should try to
>reproduce it and take a look at it.
This
On 6/17/12 8:26 PM, Adrian Chadd wrote:
Hiya,
don't suppose you could file a PR for this?
Typing one up just now, after figuring out the root cause.
The short version is this: __uint64_t gets defined in
as unsigned long. This breaks when you use -m32, in
which case sizeof(unsigned long)
Hiya,
don't suppose you could file a PR for this?
Adrian
On 17 June 2012 16:10, Eric McCorkle wrote:
> On 6/17/12 6:45 PM, Eric McCorkle wrote:
>>
>> On 6/15/12 6:44 PM, Eric McCorkle wrote:
>>
>
>> int main() {
>> printf("%d\n", UINT64);
>> return 0;
>> }
>>
>
> Correction: it should be
On 6/17/12 6:45 PM, Eric McCorkle wrote:
On 6/15/12 6:44 PM, Eric McCorkle wrote:
int main() {
printf("%d\n", UINT64);
return 0;
}
Correction: it should be sizeof(UINT64)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org
On 6/15/12 6:44 PM, Eric McCorkle wrote:
However, the EFI programs I produce using the EDK system work
properly, and don't have the same issues as the ones I produce using
what's in the base system.
Okay, after a whole lot of slogging, I figured out the root of the
problems I've been seeing,
On 06/16/12 06:03, Andrey V. Elsukov wrote:
> Hi, Eric.
>
> Did you try the GNU EFI toolchain? It contains a good descriptions
> on how to build EFI application and we probably can use some
> suggestions even without importing it.
>
> http://sourceforge.net/projects/gnu-efi/
>
I did. It looks
On 16.06.2012 02:44, Eric McCorkle wrote:
> I've been working on EFI support for intel platforms. I've managed to
> build the EFI Development Kit (EDK II) and the IASL compiler for
> FreeBSD, which raises the possibility of integrating them either as
> ports, or possibly into the base system.
>
>
12 matches
Mail list logo
