25.03.2016, 02:11, "Guy Yur" :
> Hi,
>
> When changing the ipv6 default route I get a panic on wlock already held.
> Could be related to r293424 lock changes, haven't checked an older version
> yet.
Hi,
Yes, there is a problem when the default route next hop is filled in
incorrectly, so lookup fa
Hi Vladimir,
I believe you need x86 arch.
Regards
On Mar 24, 2016 3:37 PM, "Владимир" wrote:
> Hello, please tell me whether the FreeBSD operating system Intel Atom
> Z3735F? Which distribution I need to download?
>
>
>
> ___
> freebsd-...@freebsd.or
Hello, please tell me whether the FreeBSD operating system Intel Atom Z3735F?
Which distribution I need to download?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mai
I tried to buildworld with -Os CFLAGS, but it failed.
Here is the compiling log:
--- getcap.So ---
cc -m32 -DCOMPAT_32BIT -march=haswell -isystem
/usr/obj/usr/src/lib32/usr/include/
-L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32
-fpic -DPIC -g -Os -pipe -I/usr/src/lib/lib
Hi,
When changing the ipv6 default route I get a panic on wlock already held.
Could be related to r293424 lock changes, haven't checked an older version yet.
route add -inet6 default fe80::7
route change -inet6 default fe80::7
panic: rw_rlock: wlock already held for rib head lock @
/usr/src/sys/
On 24.03.2016 22:06, Владимир wrote:
> Intel Atom Z3735F
Both x86 (32 bit) and amd64 (64 bit) will do. It depends on available
memory. If you have 4GB or more installed, try amd64.
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
+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
Hi,
I would like to run arm64 current on an ODROID C2 (Amlogic S905 A53 64bit
ARMv8). I was going to try configuring u-boot to either use an ELF kernel
and boot it with bootelf or a kernel.bin produced with objcopy. and boot it
with the go command. I was looking at the wiki instruction page for t
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
CURRENT fails building a kernel:
[...]
--- modules-all ---
--- all_subdir_acl_posix1e ---
===> acl_posix1e (all)
--- all_subdir_acpi ---
===> acpi (all)
--- tcp_subr.o ---
/usr/src/sys/netinet/tcp_subr.c:1935:20: error: use of undeclared identifier
'tcbinfo' in_pcbnotifyall(&tcbinfo, faddr, EHOSTD
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.
Not for emulations on first step, but as a native supported format
just like a.out [or Elf]
(though it can go in both ways too).
There are good reasons to
20 matches
Mail list logo
