Hi again.
I've implemented FatElf support for Elf image activator too[1] :)
Any comments/reviews on this ?
I also pinged Ryan Gordon about this.
Also im curious to know if any comments/reviews are done on MachO
implementation[2]
Best wishes and thousands of regards, Mokhi.
=
errr, typo ...
s/an FatELF both/and FatELF both/g
:)
On 3/25/16, mokhi wrote:
> Adrian, thanks for your +1 :P
>
> So, what about EULA related things that 'David' pointed to?
> If this isn't really a big problem, I have no problem to continue on
> working on it, an FatELF both ;)
>
_
Adrian, thanks for your +1 :P
So, what about EULA related things that 'David' pointed to?
If this isn't really a big problem, I have no problem to continue on
working on it, an FatELF both ;)
___
freebsd-current@freebsd.org mailing list
https://lists.fre
+1, get mach-o up, see if we can twist other people to work on the
other missing bits to run apple stuff on freebsd. :P
-a
On 24 March 2016 at 07:26, mokhi wrote:
> So, I'll try to port FatELF as well as MachO.
> Choosing the better one is up to you ;)
>
> All opinions/idea are welcome and I a
So, I'll try to port FatELF as well as MachO.
Choosing the better one is up to you ;)
All opinions/idea are welcome and I appreciate.
Best wishes, Mokhi.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-cur
On 24 Mar 2016, at 13:42, Damjan Jovanovic wrote:
>
> ELF itself is a disaster. Symbol lookup in ELF is process scoped, not
> library scoped like Windows's PE and Mac's Mach-O, so same named
> symbols from different libraries in the same process (loaded through
> any number of levels of indirecti
ELF itself is a disaster. Symbol lookup in ELF is process scoped, not
library scoped like Windows's PE and Mac's Mach-O, so same named
symbols from different libraries in the same process (loaded through
any number of levels of indirection) can and do clash, resulting in
memory corruption. This is
On 3/24/16, mokhi wrote:
> Then you think the better idea is porting FatELF to FreeBSD, rather
> than working on MachO?
>
If yes,
I am ready to put dedicated time on it :) [as I did for MachO]
But before that, you think, is there any changes we can/should make on it?
* I read something about F
Then you think the better idea is porting FatELF to FreeBSD, rather
than working on MachO?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr..
On 3/24/16, Achim Patzner wrote:
> Would that project end in having an intelligent loader that will only map
> the relevant architecture to memory (i. e. I’ll have extremely fat
> executables supporting any known architecture in the universe on /usr/local
> or even for all files that can be shared
On 24 Mar 2016, at 12:05, mokhi wrote:
>
> Hi.
>
> I'm agreed with point you told about improvements we can do for fat
> format (or more).
> And I'm ready to do them (with your helps, sure :D).
>
> But we need short steps and more of them (a local proverb :D) IMO.
> If we completely do this ima
Hi.
I'm agreed with point you told about improvements we can do for fat
format (or more).
And I'm ready to do them (with your helps, sure :D).
But we need short steps and more of them (a local proverb :D) IMO.
If we completely do this image activator, then we can have 2 sub plans
for OSX emulatio
Hi,
I’d slightly question the assertion that Mach-O is a well-designed format. For
example, it has a hard limit of 16 section types, doesn’t support COMDATs and
so on. OS X uses a load of magic section names to work around these
limitations.
Note that a Mach-O image activator is relatively e
> Am 24.03.2016 um 10:13 schrieb mokhi :
>
> Hi guys.
> I'm Mahdi Mokhtari (aka Mokhi between FreeBSD friends).
>
> I am working on adding Mach-O binary format to supported formats for FreeBSD.
Would that project end in having an intelligent loader that will only map the
relevant architecture
14 matches
Mail list logo
