I would start to debug the issue by replacing your non-working CGI script with a very simple script which just dumps the environment. Then compare the output you get from within the webserver with what you get when you run the same CGI script from the command line.

A default Apache installation even comes with such a script, called printenv (written in Perl), so you don't have to write it yourself.

My guess is that the compiler is not found or available to the user that the web server runs as. Command line is not usually the same environment as a service.

Well I don't know if I got you exactly right but I have to mention that I am running the tests on localhost. So this is the same computer.

So this is the same computer.

Did you try it with the same user account under which your web server runs? This is almost always a permissions issue. Running the program successfully from your user account tells you only that the program runs, not that it will run from the web server.

Is Apache running as a service? If, what do you see in the "Log On As" column (last column) for Apache2 when you run the command:

mmc %systemroot%\system32\services.msc
[download]

Hey... yes it is running as a service and I see "Local System" there

yes it is running as a service and I see "Local System" there

Then, as identified by those above, your script is running under a different account ("Local Service") when run from Apache2 than when you are running it from the command line. Hence it is subject to different permissions.

You need to change the account Apache2 is run as:

Right click the Apache2 service line, click "Properties", then the "Log on" tab, then "This account" and enter (or select) a username and password.

And ensure that the user you choose has appropriate permissions (NOT an Administrator account!).

But be aware! If this is an external facing machine, changing these permissions can expose your machine to intrusions. If you don't know what you're doing, ask someone who does. (Eg. Your local SysAdmin).

Or, move all the files (The script itself plus all the Inline::C temporary directories and files) underneath your script-enabled Apache cgi-bin directory. But as I always found Apache configuration too messy to bother with, you'll need someone else to tell you how to do that.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Further to the above, probably the quickest fix is just to grab the Inline generated XS out of /build and use that directly (ie drop Inline out of the equation). All you need to go with the XS is a very short .pm to Dynaload it. h2xs will generated a stub XS example for you. Just paste in the autogenerated inline C XS and the INLINE.h and it should compile and install fine. Then in the scipt just use the module as normal. This will work and is almost certainly a more reliable solution as you have removed an abstraction layer.

Now this is what I was thinking: build a proper XS module instead of using the Inline::C shortcut. No reason to force compilation on the web server process, especially if it doesn't work properly anyway.

As a general question, I was wondering how Inline::C is used in production applications. My instinct is that Inline::C is more of a helper/get-me-started module, not something to be used in the final shipped application. Seeing how the OP solved the original problem confirms it for me: library and header include paths shouldn't be hard-coded in the Perl code; stuff like that belongs in a build process.

On the other hand, my impression is that Inline::C is a very popular module. Is it accepted practice to include C code using it? Would I find modules on CPAN that depend on Inline::C?

We do have some Perl at $work, but mostly just for utility scripts, and we've never had to write any C code. I'm curious what the general accepted practice is in the Perl community.

You can use Google to "grep" cpan site:cpan.org/src "use Inline C" returns 30 results (click the last button to make Google find the real number, not the estimate). About 1/2 are .pm modules using Inline C, so the answer is not very many.

h2xs is a powerful tool worth looking into.

There is a moduleInlineX::XS that converts Inline::C code to XS although I have not tried it. There are also InlineX::C2XS InlineX::CPP2XS for C++

I think this is likely to be a bug with Inline/Apache. When you use Inline::C what happens under the covers the first time you run it is rather complicated. In a nutshell your code gets parsed, converted to XS/C and then that gets compiled. The generated XC/C is found in cwd/_Inline/build/script_name_xxxx/. The actual executable objects are found in cwd/_Inline/lib/script_name_xxxx/ where the xxxx is the same as the build name.

At runtime Inline looks to see if it needs to be compiled, and if so runs a compile then execute. If it has already been compiled it just executes.

I can see multiple issues. First if you have run it you should not need cl.exe as it has already been compiled. The fact that your browser can't find cl.exe but you obviously can (it runs from the command line) indicates you are running with different paths to the web server.

Anyway the server/perl should not need to compile this once it has been run off the command line once. If you look at the can't load statement you will see an issue with the path - it has \ and / path separators. As you checked to ensure sunucuya_yukle_cgi_485e.dll is there I wounder if a quick hack in Dynaloader to change the \ to / would fix it?

    foreach (@INC) {
    
        s!\\!/!g;                       # apachify path Win32
        my $dir = "$_/auto/$modpname";  # here is the \ / problem
    
    next unless -d $dir; # skip over uninteresting directories
    
    # check for common cases to avoid autoload of dl_findfile
    my $try =  "$dir/$modfname.dll";
[download]

Hello everyone! I have solved the issue and here is how:

First of all I followed the advice which said run printenv.pl both on command line and in a web browser and I saw that the env. variable path had different content. So I copied all the path information from my private windows account env. vars to system env. vars. I also added the folder which is named /MSVC6/VC98/COMMON which contains, I believe, the dll files that cl.exe needs. This solved the compilation problem.

Secondly, I started getting include errors which I hadn't been getting had I compiled the code from the command line. So I Included the folder(s) that contained the header files that could not be located by the compiler inside the expression:

use Inline (C => Config => LIBS => '-LC:\OpenCV\lib -lcv.lib -lcxcore.
+lib -lhighgui.lib -LC:\MSVC6\VC98\LIB',
                   INC => '-IC:\MSVC6\VC98\INCLUDE');
[download]

After all these, I was only getting the bootstrapping error which got automatically solved when I restarted the system.

Thank you all for your invaluable efforts to help me. It's because of you that I could complete a difficult task for myself.

Hvala!! Tesekkürker!! :)

One of the first rules they teach sysadmins, is NEVER let "the world", i.e. a web client, have access to a c compiler. Especially on win32. Thats a great way to get a virus.

Thanks for the advice... I will keep it in mind! But I don't think that it will be a problem in this case in particular simply because this app will be running somewhat internally. So there will be no access to it from outside. But really thanks for the advice... I will consider it when it comes to security issues

<p mode="sarcastic">What is your network again? I want to dump it into my border firewall's blacklist as a self protection mechanism</p>

In all seriousness, it is worth the extra effort to learn to do it with minimal privileges up front, because it forces you to think of the reprecussions of the actions you are allowing the web server to accomplish.

Too many times I have seen $management ask to have Joe External be able to use an "internal" application. Applications morph. Unless you limit up front what the application is able to do from a security standpoint (only what it needs to do), it is just too easy to make decisions later on without thinking through the implications.

On the other hand, I started life as a security focused system admin, so I am a little more paranoid about those things.

Update: And a P.S. "somewhat internal" means external, right? It is either 100% internal, or it is external.

--MidLifeXis

I'm curious. What does the C code do that you couln't do in Perl? Maybe you can avoid to use Inline at all.


holli, /regexed monk/