Re: $ORIGIN (was: Re: make: ensure ${.MAKE} works)

On Wed, Apr 28, 2010 at 02:57:47PM -0400, der Mouse wrote:
 >>> To wit: as far as I can tell, having been wading around in that code
 >>> recently, the only problem with what we have is that if the path
 >>> sent back by namei isn't absolute it needs a getcwd() stuck on the
 >>> front of it.
 > 
 >>> Is it reasonable to just do that?
 > 
 > I don't think so.  It would be a regression in that it would break
 > things in no-path-up-to-/ situations; it also would either fail or
 > expose paths that shouldn't be accessible in path-to-/-isn't-readable
 > situations.

Does anyone know how other implementations of $ORIGIN deal with these
cases?

For the time being, even if we just provide a relative path when
getcwd fails it'd still be more functional than the current situation.

 > > Why not get the kernel to keep a reference to the vnode of the
 > > directory that contained the process image?
 > 
 > > Then use some flag to open() (or similar) to open a file relative to
 > > that vnode?

Someone already invented $ORIGIN with absolute paths and we ought to
support that, especially since we already have a half-baked
implementation.

I've often thought something like this (keeping the directory) would

Re: $ORIGIN (was: Re: make: ensure ${.MAKE} works)

In article <20100503050601.GA4400 <at> netbsd.org>,
David Holland  <dholland-tech <at> netbsd.org> wrote:
>
>For the time being, even if we just provide a relative path when
>getcwd fails it'd still be more functional than the current situation.

This would be a security flaw, because a program that chdir's could
find the wrong shared libraries.

christos

Porting NetBSD make to Interix

I wonder if someone could guide me in porting NetBSD make to Interix.

As usual with NetBSD source, make builds out of the box in Interix. But,
when running the make tests however, bmake hangs and there are error
messages.

Any clues or tips?

ksh output attached

$ uname -X

System = Interix
Node = max
Release = 6.1
Version = 10.0.7063.0
Machine = genuineintel
Processor = Intel64_Family_6_Model_26_Stepping_4
HostSystem = Windows
HostRelease = 6.1
HostVersion = SP0

$ uname -a
Interix max 6.1 10.0.7063.0 genuineintel Intel64_Family_6_Model_26_Stepping_4

$ ./bmake -r -m / TEST_MAKE=./bmake
comment testing start
this is foo

Re: Porting NetBSD make to Interix

On Fri, May 07, 2010 at 01:01:26PM +0200, Jerker Bäck wrote:
> I wonder if someone could guide me in porting NetBSD make to Interix.

Check pkgsrc/devel/bmake.

Martin

Re: Porting NetBSD make to Interix

On Fri, 07 May 2010, Jerker Bck wrote:
> I wonder if someone could guide me in porting NetBSD make to Interix.
> 
> As usual with NetBSD source, make builds out of the box in Interix. But,
> when running the make tests however, bmake hangs and there are error
> messages.

Up to (but not including) the "<ctrl>C" at the end of the output you
presented, everything looked fairly normal to me.  (The error messages
looked pretty much as expected, according to the "test.exp" file.)  Did
you press control-C to abort the test?

If there really is a problem, then the output from "${MAKE} test" in the
unit-tests directory would probably be more useful than the output from
"make all" in that directory.

--apb (Alan Barrett)

Re: Porting NetBSD make to Interix

The problem you refer to looks identical to one recently fixed for 
SunOS and their compiler.  

If you are using bmake, simply define FORCE_POSIX_SIGNALS.

The problem is that make is using both sigaction() and signal().
On NetBSD this does not matter but on system V'sh systems, it will
result in missing SIGCHLD.

If you want to build native NetBSD make you will need to edit util.c
and add something such that the signal function that wraps sigaction is
compiled for your system.

--sjg

Re: Porting NetBSD make to Interix

On Wed, May 12, 2010 at 06:12:00PM -0700, Simon J. Gerraty wrote:
 > The problem is that make is using both sigaction() and signal().
 > On NetBSD this does not matter but on system V'sh systems, it will
 > result in missing SIGCHLD.
 > 
 > If you want to build native NetBSD make you will need to edit util.c
 > and add something such that the signal function that wraps sigaction is
 > compiled for your system.

Wouldn't it be a better plan to define a makesignal() or something
that always calls sigaction?

--

-- 
David A. Holland
dholland <at> netbsd.org

PCC (pcc-libs/csu/netbsd/crtbegin.c) doesn't build in NetBSD-5

I'm not sure if this is supposed to work in the netbsd-5 branch or not,
but I just tried to build PCC there by setting MKPCC=yes in mk.conf
and the following errors resulted.

Can anyone help explain why and maybe suggest how to fix it?

    compile  crtstuff/crtbegin.o
{standard input}: Assembler messages:
{standard input}:315: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:316: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:320: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:321: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:325: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:326: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:333: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:334: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:337: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:338: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:341: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:342: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:345: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:346: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:349: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:350: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:356: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:357: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:360: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:361: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:367: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}
{standard input}:368: Error: can't resolve `.dtors' {.dtors section} - `.Ltext0' {.text section}

Listing of emergency medicine physicians and 34 more specialties

Here's some of the healthcare lists we have:

Alternative Medicine - 1,141,602 total records with 36,320 emails and 38.935 fax numbers
Dentists - 164k records, 45k emails, 77k fax numbers
Psychologists - 272,188 records and 9,874 emails

Theres many more too, just send me an email here for additional info/samples: Alejandra.Stern <at> inspireresults.info

to terminate please send a blank message to disappear <at> inspireresults.info

Re: PCC (pcc-libs/csu/netbsd/crtbegin.c) doesn't build in NetBSD-5

On Tue, 18 May 2010, Greg A. Woods wrote:

> I'm not sure if this is supposed to work in the netbsd-5
branch or not,
> but I just tried to build PCC there by setting MKPCC=yes
in mk.conf
> and the following errors resulted.

in netbsd-5 branch, I think not .. I fixed a few problems in
the 'netbsd
native' build in -current though

> Can anyone help explain why and maybe suggest how to fix
it?
>
>     compile  crtstuff/crtbegin.o

these files have been disabled in -current as they are not
needed at this
time. (I left libpcc in the build but I don't think that is
required
either)

In truth, you will be better served by checking out a later
version of pcc
and using ./configure manually than attempting to use the
one in tree as
much development has been done (not sure about the pkgsrc
version I
haven't tried it). I have some plans to import a recent