Bypass compiler ENVIRON() check for fbFindBinFile()

[McLovin]

Here is the situation: I use various compilers via a USB hard drive. At work the computers are locked down pretty good so you need administrative rights to install software, blah blah blah, so if my compiler doesn't run from the USB hard drive then I'm out of luck. I have always had trouble running the FB compiler because it would fail indicating the the "executable was not found".

Yesterday, I did some modifications on the compiler source code and narrowed the problem to the "fbFindBinFile" function which attempts to create a fully qualified path to the assembler, linker, etc... The problem occurs when the compiler attempts to retrieve the ENVIRON setting from the system. I guess because the computer is pretty much locked down, the function returns the server name rather than an empty string (why? I have no idea.). Of course, the server name is not where the executables are located so the hFileExists function fails and generates the "executable not found" error.

Having said all that, I am thinking that I should be able to feed to the compiler an option to bypass checking for the environment variable. I think that can be done via the "-d" compiler switch???? I have tried several attempts but each does not work:

fbc -d FB_FINDBIN_ALLOW_ENVVAR=0
fbc -d FB_DEFAULT_FINDBIN=0
fbc -d FB_COMPOPT_FINDBIN=0

Am I missing something here? Should any of the above work?

I could modify the source code to skip the ENVIRON check but that means that I would always have to modify everytime I download new compiler source code. It is inconvenient but I'll only do that as Plan B.

Thanks!

[dkl]

FBC can be built as "stand-alone", if this is done, it uses relative paths instead of full paths.
You can find that out by running "fbc -version", if it is a stand-alone version with relative paths it would show a "Configured as standalone" line like here:

>fbc -version
FreeBASIC Compiler - Version 0.21.0 (11-11-2008) for win32 (target:win32)
Copyright (C) 2004-2008 The FreeBASIC development team.
Configured as standalone
objinfo enabled using C BFD wrapper

Imortis offers up-to-date win32 SVN builds that are configured as stand-alone here:
http://www.freebasic.net/forum/viewtopic.php?t=12614

(The -d command line option of FBC can be used to set a preprocessor #define when compiling code.)

[McLovin]

Hi dkl,

Yes, I am using version 0.21.0 as Standalone (win32). I am using a version that I compiled yesterday. Therefore, I think that the ENVIRON check is done regardless of standalone or not. Here is the version information of the fbc I have.

fbc -version

FreeBASIC Compiler - Version 0.21.0 (11-11-2008) for win32 (target:win32)
Copyright (C) 2004-2008 The FreeBASIC development team.
Configured as standalone
objinfo enabled using FB BFD header version 217


Thanks

[dkl]

Well, strange, I actually remember having the "executable not found" error some time ago, but can't remember when/how exactly... I think it had to do with a corrupt build, with "bad" paths, caused by some mix-up of configuration, old/new object files and whatever. Have you tried to re-run the configure script? or completely make clean and rebuilt fbc?

Anyways, just now I removed all references to fbc's binaries/binutils/MinGW from PATH, fbc is still working fine.

I also tested on another computer using the guest account (of course no entrys in PATH), which also worked fine.

Currently I'm copying FB onto an USB stick to see how it works from there.

[McLovin]

I modified the source code and re-compiled with the following change to the fbFindBin function:

Code: Select all

#ifndef STANDALONE
	'' get from environment variable if allowed
	if( (opts and FB_FINDBIN_ALLOW_ENVVAR) <> 0 ) then
		path = environ( ucase(*filename) )
		if( len(path) ) then
			isenv = TRUE
		end if
	end if
#endif

Wrapping the code to test for STANDALONE has fixed my problem.

Any chance that maybe a developer here can add this change to the CVS? It would certainly help in the future when I download the daily source code snapshots.

Thanks!

[counting_pine]

The problem occurs when the compiler attempts to retrieve the ENVIRON setting from the system. I guess because the computer is pretty much locked down, the function returns the server name rather than an empty string (why? I have no idea.).

This sounds like it shouldn't happen.
Have you tried experimenting yourself with the environ()? What happens if you use *getenv() directly? You can access it through crt.bi.

[McLovin]

Yes you're right and I did a little bit further investigation. Only the "AS" environment variable fails. Attempts to get the other bin paths all work. It looks like on this system that the admins set the "AS" environment variable to equal the server name. I'm not sure what purpose it is used for but I really shouldn't be messing with deleting it anyway in case it cause system stability problems.

I guess this brings up an interesting question. Let's say that environment variables like "AS", "LR", "LD" are used by other applications and refer to things totally different than the gcc tools. This conflict would cause either the FB compiler to fail or that other application to fail. I guess a batch file could be made that SETs the variable, calls the compiler, and then resets it afterwards. Kind of a kludge though.

But if configured as STANDALONE shouldn't FB just use the relative path from the compiler rather than even look for alternate paths? It seems like the ENVIRON check would override the STANDALONE directive if the environ variable happens to be set.

[counting_pine]

I don't know whether or not they should be checked on standalone, but it's not as much of a kludge removing the AS variable as you might think. The changes you make to environment variables will only affect the cmd session or app they're changed in, so you don't have to worry about reverting the variable, or breaking anything system-wide.

[McLovin]

thanks counting_pine - you're exactly right. I forgot that a copy of the environment is used when shelled to cmd/command. I've been using the compiler via the usb hard drive for the past couple of days with no trouble. Lots left to learn about the compiler source code - hopefully someday soon I'll have enough knowledge to actually help provide some meaningful patches. Everyone has to start somewhere.

:-)