CGI/perl Compilierung

[Winston]

Hallo,
ich würde gerne eine CGI-Webanwendung zu einer ausführbaren Datei oder Resource compilieren, so dass der Quellcode unersichtlich wird.
Dabei sollten die Aufrufe aus HTML und die Interaktion untereinander nicht beinträchtigt werden. Hat dazu jemand eine Idee?
'perlcc' funktioniert unter Windows-Plattformen leider nicht, sonst hätte ich darüber mal mein Glück probiert.
Gruß
Winston

[Philipp Hasenfratz]

Halihallo Winston

ich würde gerne eine CGI-Webanwendung zu einer ausführbaren Datei oder Resource compilieren, so dass der Quellcode unersichtlich wird.
Dabei sollten die Aufrufe aus HTML und die Interaktion untereinander nicht beinträchtigt werden. Hat dazu jemand eine Idee?
'perlcc' funktioniert unter Windows-Plattformen leider nicht, sonst hätte ich darüber mal mein Glück probiert.

1. Vorschlag:
eventuell kannst du irgendwas mit cygwin machen. Das emuliert ja Unix und vielleicht kriegst du auch perlcc darunter zu laufen (irgendwie...)

2. Vorschlag:
Mit Content Negotiation (s. hierzu auch gzip_cnc: http://www.schroepl.net/projekte/gzip_cnc/ ;)) kannst du jede Anfrage auf ein .cgi oder .pl abfangen und zu einer entsprechenden .exe Datei weiterleiten, welche du vorher mit perl2exe kompiliert hast (dann brauchst du zumindest nicht jedes Forumlar auf .exe umzustellen). Ist zwar einiges an Aufwand, aber es ist zumindest ein Lösungsansatz.

Ist wahrscheinlich nicht sehr hilfreich, aber ich habe leider keine bessere Lösung bereit.

Viele Grüsse

Philipp

PS: Kompilierte Perlprogramme mit perl2exe sind jedoch langsamer, als wenn du den Interpreter verwendest!

[Christoph Schnauß]

hallo Philipp,

1. Vorschlag:
   eventuell kannst du irgendwas mit cygwin machen. Das emuliert ja Unix

das halte ich nicht für sinnvoll, weil  -  soviel ich weiß  -  damit keine exe kompiliert werden kann

2. Vorschlag:
   Mit Content Negotiation (s. hierzu auch gzip_cnc: http://www.schroepl.net/projekte/gzip_cnc/ ;)) kannst du jede Anfrage auf ein .cgi oder .pl abfangen und zu einer entsprechenden .exe Datei weiterleiten, welche du vorher mit perl2exe kompiliert hast
   Kompilierte Perlprogramme mit perl2exe sind jedoch langsamer, als wenn du den Interpreter verwendest!

schon besser. Dann sollte man der Vollständigkeit halber noch sagen, wo man perl2exe herbekommt:http://www.indigostar.com/perl2exe.htm. Ich würde eine mit perl2exe erstellte Executable aber nicht als CGI-Anwendung einsetzen. Gedacht ist perl2exe dazu, daß man standalone-Anwendungen erstellen kann

interessant wäre noch die Frage nach der Begründung, die Winston liefert:

ich würde gerne eine CGI-Webanwendung zu einer ausführbaren Datei oder Resource compilieren, so dass der Quellcode unersichtlich wird.

warum soll das "unübersichtlich" werden? Jeder andere, der CGI-Scripts schreibt, würde sich ganz im Gegenteil um möglichs große Klarheit und Übersichtlichkeit bemühen. Außerdem gehts um "CGI-Webanwendung" und da kann man auch was mit C/C++ machen

Grüße aus Berlin

Christoph S.

[Philipp Hasenfratz]

Halihallo Christoph

schon besser. Dann sollte man der Vollständigkeit halber noch sagen, wo man perl2exe herbekommt:http://www.indigostar.com/perl2exe.htm. Ich würde eine mit perl2exe erstellte Executable aber nicht als CGI-Anwendung einsetzen. Gedacht ist perl2exe dazu, daß man standalone-Anwendungen erstellen kann

Stimmt, aber Winston will ja eben .exe Files als Standalone-Anwendungen und mit perl2exe kann man natürlich auch CGI-Progis erstellen.

interessant wäre noch die Frage nach der Begründung, die Winston liefert:

ich würde gerne eine CGI-Webanwendung zu einer ausführbaren Datei oder Resource compilieren, so dass der Quellcode unersichtlich wird.
warum soll das "unübersichtlich" werden? Jeder andere, der CGI-Scripts schreibt, würde sich ganz im Gegenteil um möglichs große Klarheit und Übersichtlichkeit bemühen. Außerdem gehts um "CGI-Webanwendung" und da kann man auch was mit C/C++ machen

Er meinte "unersichtlich". Er möchte, dass der Quellcode seiner CGI-Progis nicht sichtbar ist, deshalb die Kompilierung. Wahrscheinlich will er vorgefertigte CGI-Programme kommerziell anbieten. Pfui, pfui, Winston :-)

Viele Grüsse

Philipp

PS: perlcc funktioniert vielleicht nicht, aber es ist auch möglich einen Perlinterpreter über #include in die .c - Datei einzubinden und dann den Perlcode in eine .c Datei zu schreiben. Diese lässt sich dann ganz einfach über einen C-Compiler kompilieren (eben auch unter Windows) und dann hast du das selbe Resultat, wie wenn du perlcc anwendest.

[Christoph Schnauß]

hallo Philipp,

perlcc funktioniert vielleicht nicht, aber es ist auch möglich einen Perlinterpreter über #include in die .c - Datei einzubinden und dann den Perlcode in eine .c Datei zu schreiben. Diese lässt sich dann ganz einfach über einen C-Compiler kompilieren (eben auch unter Windows) und dann hast du das selbe Resultat, wie wenn du perlcc anwendest.

sehr interessanter Vorschlag. Kannst du mal ein Beispiel herschreiben? Beispielsweise für ein Perl-Script dieser Art:

#!D:/perl/bin/perl.exe -w
print "Content-type: text/html\n\n";

print "<b>dieses script liest die Umgebungsvariablen aus und stellt sie am Bildschirm dar. Es gibt damit lediglich einen Test, ob perl installiert und ein Webserver aktiv ist</b><p>\n";
print "<b>heutiges Datum: ", scalar localtime, "</b><p>\n";

print "%ENV: <br><br>\n", map { "$_ = $ENV{$_} <br>\n" } keys %ENV;

Grüße aus Berlin

Christoph S.

[Philipp Hasenfratz]

Halihallo Christoph

perlcc funktioniert vielleicht nicht, aber es ist auch möglich einen Perlinterpreter über #include in die .c - Datei einzubinden und dann den Perlcode in eine .c Datei zu schreiben. Diese lässt sich dann ganz einfach über einen C-Compiler kompilieren (eben auch unter Windows) und dann hast du das selbe Resultat, wie wenn du perlcc anwendest.

sehr interessanter Vorschlag. Kannst du mal ein Beispiel herschreiben? Beispielsweise für ein Perl-Script dieser Art:

[...]

Ich habe leider keine Ahnung, wie das in der Praxis funktioniert. Leider habe ich bisher keine Erfahrungen damit gemacht (aber mein Interesse ist soeben erweckt ;)). Ich kann nur auf die perldoc perlembed verweisen, mit google hab ich bisher auch keine wirklich 'gscheiten Seiten gefunden. Ich glaube jedoch, dass Christian Kruse bestimmt helfen kann (ich glaube mal gelesen zu haben, dass sich Christian damit beschäftigt(e)).

Hab mal folgendes aus perldoc zusammengeschnippselt, jedoch nie getestet:

test.c:
    #include <EXTERN.h>
    #include <perl.h>
    static PerlInterpreter *my_perl;
    int main(int argc, char **argv, char **env)
    {
        char *args[] = { NULL };
        my_perl = perl_alloc();
        perl_construct(my_perl);
        perl_parse(my_perl, NULL, argc, argv, NULL);
        /*** skipping perl_run() ***/
        call_argv("test", G_DISCARD | G_NOARGS, args);
        perl_destruct(my_perl);
        perl_free(my_perl);
    }

dazu test.pl (Sourcecode in Perl, der durch call_argv eingelesen wird):

print 'Hello World, ich bin durch C aufgerufen worden :-)';

ich nehme jedoch an, dass der Code dann nicht in die kompilierte .exe eingebunden wird, sondern, dass er jedesmal versucht die Datei einzulesen und dann "real-time" zu parsen. Jedoch kann man der Prozedur perl_parse auch einen CHAR übergeben, welcher den Perl-Code enthält, somit wird der Perl-Source wirklich in die .exe Datei eingespeist.

Viele Grüsse

Philipp

[Christoph Schnauß]

ähm, Philipp, ja ...

Hab mal folgendes aus perldoc zusammengeschnippselt, jedoch nie getestet:

wow, kann ich hinterlistig sein ;-) Hättest mal testen sollen *g*

test.c:
    #include <EXTERN.h>
    #include <perl.h>

das setzt zwei Header-Dateien voraus, die auch erst mal geschrieben sein wollen

ich nehme jedoch an, dass der Code dann nicht in die kompilierte .exe eingebunden wird, sondern, dass er jedesmal versucht die Datei einzulesen und dann "real-time" zu parsen. Jedoch kann man der Prozedur perl_parse auch einen CHAR übergeben, welcher den Perl-Code enthält, somit wird der Perl-Source wirklich in die .exe Datei eingespeist.

gewagte Thesen. Warum haste so eine Idee nicht schon am Freitag geschrieben, dann hätte ich das ganze Wochenende mit entsprechenden Basteleien verbracht ... stattdessen hab ich mir (und Orlando) den Kopf mit XHTML- und Javascript-Problemen zerbrochen :-(

Grüße aus Berlin

Christoph S.

[Philipp Hasenfratz]

Halihallo Christoph

ähm, Philipp, ja ...

Anrede??? ;-)

test.c:
    #include <EXTERN.h>
    #include <perl.h>
das setzt zwei Header-Dateien voraus, die auch erst mal geschrieben sein wollen

Die liegen im CORE-Verzeichnis von perl-lib ;-)

ich nehme jedoch an, dass der Code dann nicht in die kompilierte .exe eingebunden wird, sondern, dass er jedesmal versucht die Datei einzulesen und dann "real-time" zu parsen. Jedoch kann man der Prozedur perl_parse auch einen CHAR übergeben, welcher den Perl-Code enthält, somit wird der Perl-Source wirklich in die .exe Datei eingespeist.

gewagte Thesen. Warum haste so eine Idee nicht schon am Freitag geschrieben, dann hätte ich das ganze Wochenende mit entsprechenden Basteleien verbracht ... stattdessen hab ich mir (und Orlando) den Kopf mit XHTML- und Javascript-Problemen zerbrochen :-(

Na, ja, ist doch auch ganz nett ;-)
Armer du ;-)
Aber bitte, jetzt hast du ja noch die ganze Nacht Zeit (oder musst du bis in die Nacht "richtig" arbeiten, dass etwas Geld in die Tasche kommt?) ;-)

Viele Grüsse

Philipp

PS: Irgendwie hast du mich jetz völlig verwirrt; hab nämlich keine Ahnung, wie ich dein Posting werten soll. Hast du nicht einige <ironie>...</ironie> vergessen?

[Christoph Schnauß]

hallo Philipp ;-)

ähm, Philipp, ja ...
Anrede??? ;-)

ja, war denn das keine?

das setzt zwei Header-Dateien voraus, die auch erst mal geschrieben sein wollen
Die liegen im CORE-Verzeichnis von perl-lib ;-)

oh Wunder, bei mir liegen sie dort auch, sogar auf allen Systemen. Aber wie soll jetzt mein C-Compiler da rankommen? Ich habe auf Windows VisualC++ 6 und auf LINUX bzw FreeBSD als "default" den guten alten gcc. Wie sollen die nun auf diese Headerdateien zugreifen?
(du merkst, ich will bloß, daß du deine Idee unserem Thread-Ausgangsposting-Verfasser _nachvollziehbar_ erklärst)

Aber bitte, jetzt hast du ja noch die ganze Nacht Zeit (oder musst du bis in die Nacht "richtig" arbeiten, dass etwas Geld in die Tasche kommt?) ;-)

eben nicht ;-( zum Geldverdienen muß ich in zehn Stunden wieder ausm Bett fallen. Heute hab ich keins verdient, sondern bloß welches ausgegeben (Verbindungskosten)

Hast du nicht einige <ironie>...</ironie> vergessen?

Hab ich keineswegs. Aber noch hab ich leider keine Möglichkeit, Antwortpostings als XML-Dateien mit eigener DTD an die Forums-Hauptdatei zu übergeben

arbeitsame Grüße

Christoph S.

PS: WARNUNG: wenn du antwortest, und ich was finde, worauf ich nochmal einsteigen müßte, ändere ich den Threadtitel zu "jetzt schreiben wir nen Feature-Artikel"

[Philipp Hasenfratz]

Halihallo Christoph

ich wag mal den Versuch nochmals zu Antworten (aber etwas OT), trotz Warnung :-)

ähm, Philipp, ja ...
Anrede??? ;-)
ja, war denn das keine?

Äm, doch, doch, 'tschuldige :-)

das setzt zwei Header-Dateien voraus, die auch erst mal geschrieben sein wollen
Die liegen im CORE-Verzeichnis von perl-lib ;-)
oh Wunder, bei mir liegen sie dort auch, sogar auf allen Systemen. Aber wie soll jetzt mein C-Compiler da rankommen? Ich habe auf Windows VisualC++ 6 und auf LINUX bzw FreeBSD als "default" den guten alten gcc. Wie sollen die nun auf diese Headerdateien zugreifen?
(du merkst, ich will bloß, daß du deine Idee unserem Thread-Ausgangsposting-Verfasser _nachvollziehbar_ erklärst)

Ach, das willst du also; hab mich schon die ganze Zeit über die "komischen" Postings gewundert ;)
Und ich will bloss, dass ihr versteht, dass ich absolut keinen Schimmer davon habe, was ich hier erzählen soll, so leid's mir auch tut. Ich wüsste es selber ja auch gerne. Nun, ich hab mein pseudo C-Progi mal getestet; den perl-lib in Path gesetzt und als Parameter übergeben, aber nix und wieder nix. Der will's einfach nicht finden... Hab sogar alle .lib und .h Files ins selbe Verzeichnis kopiert, auch nix... Entschuldigung, aber ich bin ein absoluter Newbie in diesem Sektor und _kann_ _nicht_ _helfen_... Da _muss_ ein anderer (z. B. CK) sich mal einschalten, denn ich komm selber nicht weiter und bin nicht im Stande diesen Thread mit Wissen weiter zu füllen :-(((

PS: WARNUNG: wenn du antwortest, und ich was finde, worauf ich nochmal einsteigen müßte

Oh, ich bitte um Entschuldigung für meine Ahnungslosigkeit, Dummheit und sinnlosen, zweckentfremdeten Postings!!

ändere ich den Threadtitel zu "jetzt schreiben wir nen Feature-Artikel"

Musst du wohl :-((
Meldet sich wer freiwillig??? - Mich würde das Thema schon sehr interessieren.

Viele Grüsse

Philipp

[Christian Kruse]

Tag Christoph, Tag Philipp,

weisst du eigentlich, dass ich deine Schreibweise des Namens
'Phillip' ziemlich komisch finde? ;-)

oh Wunder, bei mir liegen sie dort auch, sogar auf allen
Systemen. Aber wie soll jetzt mein C-Compiler da rankommen?
Ich habe auf Windows VisualC++ 6 und auf LINUX bzw FreeBSD als
"default" den guten alten gcc. Wie sollen die nun auf diese
Headerdateien zugreifen?

Das ist Kompiler-Abhaengig. BCB (Boland C++ Builder) und der GCC
genutzen zum setzen der Pfade -I (fuer #include) und -L (fuer zum
Linken (-l)). Beim MS VC++ kann man die Pfade in einem
Klickbunti-Menue einstellen (Extras->Optionen->Verzeichnisse).

Und ich will bloss, dass ihr versteht, dass ich absolut keinen
Schimmer davon habe, was ich hier erzählen soll, so leid's mir
auch tut.

Naja, was du vor 2(?) Postings geschrieben hast, war gar nicht so
verkehrt. Aber fuer Windows-Plattformen eher umstaendlich, IMHO.
Wichtig ist ueberigens beim Compile, dass du die Compiler-Flags
genau so setzt, wie du sie beim compilieren von Perl gesetzt hast!
Welche Flags das waren, duerfte sich ueber das Config-Modul erfahren
lassen.

ändere ich den Threadtitel zu "jetzt schreiben wir nen
Feature-Artikel"

Musst du wohl :-((
Meldet sich wer freiwillig??? - Mich würde das Thema schon sehr
interessieren.

Hm. Hab schon lange keinen FA mehr geschrieben -- ich glaub, ich
mach das mal.

Gruesse,
 CK

[Klaus Mock]

Hallo,

Wichtig ist ueberigens beim Compile, dass du die Compiler-Flags
genau so setzt, wie du sie beim compilieren von Perl gesetzt hast!
Welche Flags das waren, duerfte sich ueber das Config-Modul erfahren
lassen.

Genauer mittels 'perl -MExtUtils::Embed -e ccopts -e ldopts'.
(laut perldoc perlembed)

Grüße
  Klaus

[Philipp Hasenfratz]

Halihallo Christian

weisst du eigentlich, dass ich deine Schreibweise des Namens
'Phillip' ziemlich komisch finde? ;-)

:-)
Danke, dass du trotzdem 'Philipp' verwendest...

oh Wunder, bei mir liegen sie dort auch, sogar auf allen
Systemen. Aber wie soll jetzt mein C-Compiler da rankommen?
Ich habe auf Windows VisualC++ 6 und auf LINUX bzw FreeBSD als
"default" den guten alten gcc. Wie sollen die nun auf diese
Headerdateien zugreifen?

Das ist Kompiler-Abhaengig. BCB (Boland C++ Builder) und der GCC
genutzen zum setzen der Pfade -I (fuer #include) und -L (fuer zum
Linken (-l)). Beim MS VC++ kann man die Pfade in einem
Klickbunti-Menue einstellen (Extras->Optionen->Verzeichnisse).

Hab ich mal probiert.
gcc hello.c -o hello.exe -l c:\perl\lib\core

aber nix... Schade...
Hab ich mit dem Borland C++ Builder und dem GCC von cygwin getestet.

Und ich will bloss, dass ihr versteht, dass ich absolut keinen
Schimmer davon habe, was ich hier erzählen soll, so leid's mir
auch tut.

Naja, was du vor 2(?) Postings geschrieben hast, war gar nicht so
verkehrt. Aber fuer Windows-Plattformen eher umstaendlich, IMHO.

Hab leider noch nie ein perlcc für Win gesehen, deshalb muss man das wohl so machen.

Wichtig ist ueberigens beim Compile, dass du die Compiler-Flags
genau so setzt, wie du sie beim compilieren von Perl gesetzt hast!
Welche Flags das waren, duerfte sich ueber das Config-Modul erfahren
lassen.

Na, ja, ich bin grad am lernen ;-)
Wollte schon immermal mit C anfangen (das war bisher immer die grösste Kritik an mich selber und das grösse "schwarze Loch" in Sachen Programmiersprachen). Hab mir auch schon einige Dokus besorgt und das primitivste "hello world" programm (nur C, kein Perl drinne) konnte ich auch schon compilieren ;-)

ändere ich den Threadtitel zu "jetzt schreiben wir nen
Feature-Artikel"

Musst du wohl :-((
Meldet sich wer freiwillig??? - Mich würde das Thema schon sehr
interessieren.

Hm. Hab schon lange keinen FA mehr geschrieben -- ich glaub, ich
mach das mal.

Ja! Ja! - Sag bitte bescheid, wenn du's machst bzw. gemacht hast. Würd mich riesig freuen, wenn du dir die Zeit dazu nehmen würdest; schliesslich lerne ich gerne dazu.

Viele Grüsse

Philipp

[Christian Kruse]

Tag Philipp,

weisst du eigentlich, dass ich deine Schreibweise des Namens
'Phillip' ziemlich komisch finde? ;-)

:-)
Danke, dass du trotzdem 'Philipp' verwendest...

Aber gerne doch ;-)

Hab ich mal probiert.
gcc hello.c -o hello.exe -l c:\perl\lib\core

aber nix... Schade...

Na, kein Wunder, ist ja auch falsch.

gcc -o hello.exe hello.c -Lc:\perl\lib\core [... weitere Flags ...]

Die weiteren Flags erfaehrst du mit der Methode, die eins hier
drunter gepostet wurde.

Hab leider noch nie ein perlcc für Win gesehen, deshalb muss man
das wohl so machen.

Bytecode kann man auch mit dem Windows perlcc machen.

Gruesse,
 CK

[Philipp Hasenfratz]

Halihallo Christian

Hab ich mal probiert.
gcc hello.c -o hello.exe -l c:\perl\lib\core
aber nix... Schade...
Na, kein Wunder, ist ja auch falsch.

gcc -o hello.exe hello.c -Lc:\perl\lib\core [... weitere Flags ...]

Hm, hm. erstmal vielen Dank für den Hinweis. Schnell mal ausprobiert... Ach ne, der kann die EXTERN.h und perl.h immer noch nicht finden, trotz korrekter Verzeichnisangabe; dann kommen 5 Compilererrors aufgrund Folgefehler (natürlich, die Interpreterinstanz ist ja dann nicht importiert)...

Hab's mal mit dem BCC32 5.5.1 für Win probiert:

bcc hello.c -o hello.exe -Lc:\perl\lib\core -Ic:\perl\lib\core

also auch mit include-Verzeichnis... Ich hab zwar frecherweise die übrigen compiler-flags weggelassen (ich wär schon froh, wenn er Headerfiles finden würde); könnte das nichtauffinden der EXTERN.h und perl.h mit dem Zusammenhängen? - Glaub nicht, oder?

Wär toll, wenn mir da jemand etwas unter die Arme greifen könnte, denn stehen hab ich anscheinend noch nicht gelernt...

Die weiteren Flags erfaehrst du mit der Methode, die eins hier
drunter gepostet wurde.

ACK.

Hab leider noch nie ein perlcc für Win gesehen, deshalb muss man
das wohl so machen.

Bytecode kann man auch mit dem Windows perlcc machen.

Dafür würde sich Winston sicher interessieren. Ich dachte, das gäbe es nicht... Hallo Winston??? - Bist noch hier???

Vielen Dank Christian

Philipp

[Philipp Hasenfratz]

Halihallo C und C++ Freunde ;)

[...]

Hm, hm. erstmal vielen Dank für den Hinweis. Schnell mal ausprobiert... Ach ne, der kann die EXTERN.h und perl.h immer noch nicht finden, trotz korrekter Verzeichnisangabe; dann kommen 5 Compilererrors aufgrund Folgefehler (natürlich, die Interpreterinstanz ist ja dann nicht importiert)...
Hab's mal mit dem BCC32 5.5.1 für Win probiert:
bcc hello.c -o hello.exe -Lc:\perl\lib\core -Ic:\perl\lib\core
also auch mit include-Verzeichnis... Ich hab zwar frecherweise die übrigen compiler-flags weggelassen (ich wär schon froh, wenn er Headerfiles finden würde); könnte das nichtauffinden der EXTERN.h und perl.h mit dem Zusammenhängen? - Glaub nicht, oder?
Wär toll, wenn mir da jemand etwas unter die Arme greifen könnte, denn stehen hab ich anscheinend noch nicht gelernt...

Hab mich etwas umentschieden. Es war wohl zu sehen, dass es mir gehörig an Grundwissen hierzu fehlt. Deshalb hab ich mich entschieden mit dem Importieren des PerlInterpreters in C Programme zu warten und erstmal die Grundlagen zu lernen (erst noch einige "Hello World" Progrämmchen zu schreiben ;)). Sonst verschwende ich nur deine/eure Zeit... Vielleicht bin ich später auch in der Lage, dieses "Problem" selbst zu lösen...

in diesem Sinne:
Philipp goes C++ ;-)

Viele Grüsse

Philipp

[Michael Schröpl]

Hallo Leute,

das setzt zwei Header-Dateien voraus, die
auch erst mal geschrieben sein wollen
Die liegen im CORE-Verzeichnis von perl-lib ;-)
oh Wunder, bei mir liegen sie dort auch, sogar auf
allen Systemen. Aber wie soll jetzt mein C-Compiler
da rankommen?

"man gcc" fragen - ich vermute, ein "gcc -I<dirpath>"
würde ungefähr das Gewünschte bewirken.

Und nein, ich verwende normalerweise selbst kein C ...

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Klaus Mock]

Auch hallo,

das setzt zwei Header-Dateien voraus, die
auch erst mal geschrieben sein wollen
Die liegen im CORE-Verzeichnis von perl-lib ;-)
oh Wunder, bei mir liegen sie dort auch, sogar auf
allen Systemen. Aber wie soll jetzt mein C-Compiler
da rankommen?

"man gcc" fragen - ich vermute, ein "gcc -I<dirpath>"
würde ungefähr das Gewünschte bewirken.

Und für VisualC gilt "cl /I<dirpath>";-)

Grüße
  Klaus