Green, Paul wrote:
> Stephen Henson via RT wrote:
>>> [philipp_s...@redfish-solutions.com wrote:
>>>
>>> The target:
>>>
>>> fips_standalone_sha1$(EXE_EXT): sha/fips_standalone_sha1.c
>>> $(CC) $(CFLAGS) -DFIPSCANISTER_O -o $@
>>> sha/fips_standalone_sha1.c $(FIPSLIBDIR)fipscanister.o
>>>
>>> is built, but the extension is dropped when it's actually invoked:
>>>
>>> fipscanister.o: fips_start.o $(LIBOBJ) $(FIPS_OBJ_LISTS) fips_end.o
>>> ...
>>> ./fips_standalone_sha1 fipscanister.o > fipscanister.o.sha1
>>>
>>>
>>> should be "./fips_standalone_sha1$(EXE_EXT) ..." of course.
>>>
>> OK, I can fix the missing $(EXE_EXT) but this is part of the validated
>> tarball so wont be usable for FIPS.
>
> Philip, what operating system are you using or refering to? I know of
> at least two operating systems that require executable extensions on the
> *files* but neither of them requires the shell to specify the extension
> on the command line. The Stratus VOS environment is the one I'm most
> familiar with (note my email address); I'm pretty sure that MS-DOS also
> works as I describe. I've ported a *lot* of open-source software that
> doesn't bother appending the $(EXE_EXT) when it invokes a command. I'm
> really curious to know which OS works the way you describe.
>
> Thanks
> PG
Yes, on DOS (or in a CMD.EXE shell in Windows) you don't need the extension...
if your PATHEXT variable hasn't been tampered with.
In a robust build system, you can't always count on the build environment not
having been messed with.
I spent 40 minutes once tracking down an issue.... A make script wasn't
picking up the correct SVN version (it was using the construct:
svn info | awk '/^Last Changed Rev:/ { print $2 }'
and failing)... because the user had set LANG=de (he was German).
Bulletproofing the build system to not rely on the user's settings is usually
not a bad thing... unless it becomes so annotated as to be too difficult to
read.
-Philip
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
