[OpenAFS-devel] pinstall breaks fakeroot when compiling openafs for Nokia tablets

[Marcus Watts]

> Date:    Mon, 21 Jul 2008 19:09:00 EDT
> To:      Russ Allbery <rra@stanford.edu>
> cc:      openafs-devel@openafs.org
> From:    Jason Edgecombe <jason@rampaginggeek.com>
> Subject: Re: [OpenAFS-devel] pinstall breaks fakeroot when compiling openafs fo
>      ***r Nokia tablets
> 
> Russ Allbery wrote:
> > Marcus Watts <mdw@umich.edu> writes:
> >
> >   
> >> That's a clever idea.  But in the source to fakeroot-1.9.5 it looks like
> >> that's commented out -- never implemented or was removed?
> >>     
> >
> > I think it must do it some different way since I've never had a problem
> > with this using pinstall, meaning that LD_PRELOAD is getting propagated
> > somehow.  But I suppose it's possible that I'm missing some subtlety.  (I
> > guess that in practice dh_fixperms would clean things up afterwards, so
> > maybe I just don't notice.)
> >
> >   
> ok, this just gets weirder. According to Marius on the maemo-developer 
> list, pinstall should always fail because it clobbers the environment, 
> but it works after I switch to the CHINOOK_ARMEL scratchbox target. It 
> breaks when I switch back to the DIABLO_ARMEL target.
> 
> ideas?
> 
> Thanks,
> Jason
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

I'm pretty sure I don't know enough about what you're doing to have
a really well-informed idea about what might be happening - but

It *sounds* like you have 3 architectures in question here:

/1/ the host architecture.  You should tell us what that is,
but I'm assuming it's the ubiquitous intel 386 architecture.

/2/ the "CHINOOK_ARMEL" architecture.  I assume some kind of arm
processor?

/3/ The "DIABLO_ARMEL" architecture.  Some other kind of arm processor presumably.

Additionally, you are presumably doing this on a host OS, presumably ubuntu
linux.  If so, you have gnu binutils, which might be compiled for multiple
architectures or one architecture.

I think we've established that pinstall "turns off" fakeroot
for what it runs.  So, when pinstall runs, it will do a real native run
of one of these two:
	cp
	strip
it will only do strip if you haven't configured openafs to not strip
binaries.  I can't see how "cp" would care about environment variables.
The only thing that might change in your case is what the fakeroot
daemon process thinks happened - and that probably defaults to the right
thing anyways.
{	I might ask why you care about running this under
	fakeroot, but I bet you want to make a debian package.
	I think you might want to get the port to work first, then
	worry about packaging, but that's minor...	}

So the only thing I can see that you're doing that ought to break is
strip.

Again, details here could matter.  You are probably doing "elf" binaries
for all 3 architectures (host + chinook + diablo).  Elf is *somewhat*
version-independent.  It's *possible* that an elf strip that didn't
know about architecture X *might* be able to figure out enough
to strip out the symbol table.  But not very likely.  So let us
suppose you're running the ubuntu host strip, and that it's just doing
exactly what it always does on native binaries.  So here's the
interesting question: just what native binary formats does your
strip understand?

So, I happen to have "multiarch-binutils" installed on a debian linux machine.
The regular strip only knows about i386 & x86-64.  The multiarch strip
also knows about a bunch of hosts including: elf32-littlearm elf32-bigarm".
So here's a question: is CHINOOK_ARMEL "elf32-littlearm" or "elf32-bitarm"?
What about DIABLO_ARMEL?

You're running ubuntu which is not really debian.  So what do these say:
	dpkg -S /usr/bin/strip
	strip --V
Also, what does
	file /bin/cat
say when run on the 3 environments?

A simple way out of this message might be to just not strip your binaries.
If your problem is strip, that ought to vanish.  You probably want
debugging information on your port anyways, at least until you know it
won't try to give you core dumps in place of the expected results.

You also asked:
> My C is weak. Do I pass null as the third parameter to execve?
> or do I have to get a copy of the environment. what function  call gives 
> that?
> 
>         execve("/bin/cp", copy, env);
> 
> Thanks,
> Jason

"env" should be a pointer to your environment.  There's no reason to
copy it, the system call code for "exec" is going to copy it again
anyways (from the old to the new memory space.)  You should be able to
get a satisfactory value for env this way:
	extern char **environ;
	...
	execve("/bin/cp", args, environ);
Or you can let libc do that for you,
	execv("/bin/cp", args);

					-Marcus Watts