Bypass compiler ENVIRON() check for fbFindBinFile()

New to FreeBASIC? Post your questions here.
McLovin
Posts: 82
Joined: Oct 21, 2008 1:15
Contact:

Bypass compiler ENVIRON() check for fbFindBinFile()

Postby McLovin » Nov 12, 2008 17:03

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
Site Admin
Posts: 3212
Joined: Jul 28, 2005 14:45
Location: Germany

Postby dkl » Nov 12, 2008 17:38

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
Posts: 82
Joined: Oct 21, 2008 1:15
Contact:

Postby McLovin » Nov 12, 2008 17:49

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
Site Admin
Posts: 3212
Joined: Jul 28, 2005 14:45
Location: Germany

Postby dkl » Nov 12, 2008 19:15

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
Posts: 82
Joined: Oct 21, 2008 1:15
Contact:

Postby McLovin » Nov 13, 2008 16:31

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
Site Admin
Posts: 6225
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Bypass compiler ENVIRON() check for fbFindBinFile()

Postby counting_pine » Nov 13, 2008 17:25

McLovin wrote: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
Posts: 82
Joined: Oct 21, 2008 1:15
Contact:

Postby McLovin » Nov 13, 2008 18:42

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
Site Admin
Posts: 6225
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Postby counting_pine » Nov 15, 2008 1:49

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
Posts: 82
Joined: Oct 21, 2008 1:15
Contact:

Postby McLovin » Nov 15, 2008 2:23

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.

:-)

Return to “Beginners”

Who is online

Users browsing this forum: No registered users and 1 guest