>>Can anyone post sample code showing how to determine, within a Solaris
>>process space, whether a program it's about to exec is a 64-bit or
>>32-bit executable? No use saying "man file"; I have to do it within the
>>current process. And of course the next obvious response is "take a look
>>at GNU or BSD file commands and see what they do". Unfortunately I've
>>tried that and it's not working right. So if any of you have ever had to
>>do this and have a few lines of C code to post, I'd appreciate it.
> 1. Why does it matter? `execv()' doesn't need
> any special handling for a 64-bit executable.
Yes it does. There is a conceptual flaw in Suns's 32/64 bit strategy in
that it's not fully compatible with traditional SVR4 LD_* semantics. For
instance, say you set LD_PRELOAD=/somedir/somelibrary.so and then exec.
This works fine *if* the program you're executing is in the same ELF
class as somelibrary.so. If it turns out the lib is 32-bit and the
program is 64, you're SOL. You can't even catch the exec failure and try
again with a 64-bit library, because in this case it's the runtime
linker that fails *after* the exec has succeeded. The only solution is
to know what type of program you're about to execute and then set the
LD_ variable to point to the corresponding class (this applies to other
LD_* env vars, not just LD_PRELOAD).
It seems to me the only thing Sun could do to work around this problem
is to add a form of wildcarding to the LD_* EVs, e.g.:
but I'm not holding my breath.
Quote:> 2. In your current process, if there is no
> C interface to find this info out for the
> program you're about to exec, what's wrong
> with running `popen(3C)' with an appropriate
> command string to determine that for you?
> 3. /bin/file, part of Solaris, _can_ tell you
> the difference in executables -->
Perhaps you missed the place where I said "I have to do it within the
current process"? Can /bin/file answer my question _without a fork_? I