Re: CVS commit: othersrc/external/bsd/multigest

2014-10-29 Thread Alan Barrett 

On Tue, 28 Oct 2014, Alistair Crooks wrote:

+.ifndef PRINTOBJDIR
+PRINTOBJDIR=${MAKE} -V .OBJDIR
+.endif

At least for NetBSD's make(1), you need ${MAKE} -V '${.OBJDIR}' to
get the recursively-expanded value of .OBJDIR.  ${MAKE} -V .OBJDIR
would print the unexpanded value.


Oh, you'd better fix it in NetBSD's bsd.own.mk then, which was where I took
the definition above from.


It probably works because .OBJDIR is magic, and is unlikely to need
recursive expansion.

--apb (Alan Barrett)

Re: CVS commit: src/usr.bin/config

2014-10-29 Thread Christos Zoulas 
In article 20141030012621.0982...@cvs.netbsd.org,
Masao Uebayashi source-changes-d@NetBSD.org wrote:

Re: constructors/destructors:

Using them will create a portability constraint on elf. This has
the implication that rump will not work on some platforms.

christos

Re: CVS commit: src/usr.bin/config

2014-10-29 Thread Masao Uebayashi 
On Thu, Oct 30, 2014 at 10:51 AM, Christos Zoulas chris...@astron.com wrote:
 In article 20141030012621.0982...@cvs.netbsd.org,
 Masao Uebayashi source-changes-d@NetBSD.org wrote:

 Re: constructors/destructors:

 Using them will create a portability constraint on elf. This has
 the implication that rump will not work on some platforms.

Could you show me an example failure senario?  What do you propose instead?

I heard that rump fixed linkset problem using .ctors/.dtors.

But .ctors/.dtors in kernel is just analogy of the userland one; it
may use the same section names but the internal behavior can be
defferent.

Re: CVS commit: src/usr.bin/config

2014-10-29 Thread Christos Zoulas 
On Oct 30, 11:14am, uebay...@gmail.com (Masao Uebayashi) wrote:
-- Subject: Re: CVS commit: src/usr.bin/config

| Could you show me an example failure senario?  What do you propose instead?

I don't have anything *better* to propose. I think mach-o constructors
are different.

| I heard that rump fixed linkset problem using .ctors/.dtors.
| 
| But .ctors/.dtors in kernel is just analogy of the userland one; it
| may use the same section names but the internal behavior can be
| defferent.

Sure, I am not sure that all the object formats support them though.

christos

Re: CVS commit: src/usr.bin/config

2014-10-29 Thread Matt Thomas 

 On Oct 29, 2014, at 7:30 PM, Christos Zoulas chris...@zoulas.com wrote:
 
 On Oct 30, 11:14am, uebay...@gmail.com (Masao Uebayashi) wrote:
 -- Subject: Re: CVS commit: src/usr.bin/config
 
 | Could you show me an example failure senario?  What do you propose instead?
 
 I don't have anything *better* to propose. I think mach-o constructors
 are different.
 
 | I heard that rump fixed linkset problem using .ctors/.dtors.
 | 
 | But .ctors/.dtors in kernel is just analogy of the userland one; it
 | may use the same section names but the internal behavior can be
 | defferent.
 
 Sure, I am not sure that all the object formats support them though.

arm doesn’t use .ctors/.dtors 

it has init/fini array instead.

and where would they be executed?

Re: CVS commit: src/usr.bin/config

2014-10-29 Thread Masao Uebayashi 
On Thu, Oct 30, 2014 at 11:38 AM, Matt Thomas m...@3am-software.com wrote:
 arm doesn’t use .ctors/.dtors

 it has init/fini array instead.

The section names don't really matter.  Probably .kctors/.kdtors are
less confusing (+ to avoid confliction with rump).

 and where would they be executed?

Somewhere in sys/kern/init_main.c:main().  Kernel executes modules'
constructors.  I believe that Linux has already done the same way.