Kernelversion falsch?

Hallo alle miteinander,

"mimedefang" mag immer noch nicht:

mimedefang.pl --help

liefert

Errno architecture (i486-linux-2.4.32) does not match executable architecture (i486-linux-2.4.33.3) at /usr/lib/perl5/site_perl/5.8.8/Errno.pm line 11.
Compilation failed in require at /usr/lib/perl5/5.8.8/i486-linux/IO/Socket.pm line 17.
BEGIN failed--compilation aborted at /usr/lib/perl5/5.8.8/i486-linux/IO/Socket.pm line 17.
Compilation failed in require at /usr/bin/mimedefang.pl line 67.
BEGIN failed--compilation aborted at /usr/bin/mimedefang.pl line 67.

Der Kernel ist 2.6.23.12-smp (auf einer anderen Maschine 2.6.22.10).
Die Module habe ich "von früher" übernommen, und eigentlich möchte ich
ungern bei jeder weiteren Maschine erst mal ale Module neu kompilieren
(lassen); der "gentoo"-Ansatz ist nichts für pure Anwender.

Wie kann ich dem System beibringen, dass es keinen Architekturfehler
bemängelt?

Sicherheitshalber: das Problem tritt bei einigen anderen Perlskripts
(zufällig ausgesucht) nicht auf.

Viele Gruesse!
Helmut

Re: Kernelversion falsch?

Helmut Hullen wrote:
>
> Wie kann ich dem System beibringen, dass es keinen Architekturfehler
> bemängelt?

Sauberer Weg:
Das Modul Errno installieren. Die Datei Errno.pm wird passed
zum System generiert, da sie systemnahe Fehlercodes enthält.

Schmutziger Weg:
Den Test am Anfang von Errno.pm auskommentieren. Dies solltest
allerdings du nur machen, wenn du sicher bist, dass der
Architektur-Mismatch nichts ausmacht, also die Systeme
identische Fehlercodes haben.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Kernelversion falsch?

Hallo, Frank,

Du (devnull4711) meintest am 07.01.08:

>> Wie kann ich dem System beibringen, dass es keinen Architekturfehler
>> bemängelt?

> Sauberer Weg:
> Das Modul Errno installieren. Die Datei Errno.pm wird passed
> zum System generiert, da sie systemnahe Fehlercodes enthält.

Hmmm - ich habe auf einigen Maschinen einige Kernel (2.4.x.y und
2.6.x.y) installiert: kann perl sich das passende Modul je nach
Kernelversion heraussuchen?

Viele Gruesse!
Helmut

Re: Kernelversion falsch?

Hallo, Frank,

Du (devnull4711) meintest am 07.01.08:

>> Wie kann ich dem System beibringen, dass es keinen Architekturfehler
>> bemängelt?

> Sauberer Weg:
> Das Modul Errno installieren. Die Datei Errno.pm wird passed
> zum System generiert, da sie systemnahe Fehlercodes enthält.

"force install Errno" brachte die Erleuchtung: die Links in "/usr/
include" nach Linux fehlten.

mimedefang.pl

liefert jetzt die Gebrauchsanleitung.

Danke schön!

Viele Gruesse!
Helmut

Re: Kernelversion falsch?

On 2008-01-07 12:27, Helmut Hullen wrote:
> Hallo alle miteinander,
>
> "mimedefang" mag immer noch nicht:
>
> mimedefang.pl --help
>
> liefert
>
> Errno architecture (i486-linux-2.4.32) does not match executable architecture (i486-linux-2.4.33.3) at /usr/lib/perl5/site_perl/5.8.8/Errno.pm line 11.
> Compilation failed in require at /usr/lib/perl5/5.8.8/i486-linux/IO/Socket.pm line 17.
> BEGIN failed--compilation aborted at /usr/lib/perl5/5.8.8/i486-linux/IO/Socket.pm line 17.
> Compilation failed in require at /usr/bin/mimedefang.pl line 67.
> BEGIN failed--compilation aborted at /usr/bin/mimedefang.pl line 67.
>
> Der Kernel ist 2.6.23.12-smp (auf einer anderen Maschine 2.6.22.10).
> Die Module habe ich "von früher" übernommen, und eigentlich möchte ich
> ungern bei jeder weiteren Maschine erst mal ale Module neu kompilieren
> (lassen); der "gentoo"-Ansatz ist nichts für pure Anwender.

Warum willst Du das auf allen Maschinen neu compilieren und warum soll
das der Anwender tun? Bau das Paket auf einer Maschine und verteile es.
Das ist üblicherweise der Sinn einer Distribution, dass man nicht alles
auf jeder Maschine neu compilieren muss (außer bei Gentoo, und selbst da
gibt es Binary-Pakete).

(Errno.pm gehört m.W. zum Core - wenn das für eine andere Architektur
gebaut ist als das Perl-Executable (ich nehme an, das ist mit
"executable architecture" gemeint), dann hast Du irgendwas grob falsch
gemacht).


> Wie kann ich dem System beibringen, dass es keinen Architekturfehler
> bemängelt?

Eine konsistente Distribution bauen bzw. installieren.

hp

Re: Kernelversion falsch?

On 2008-01-07 14:44, Helmut Hullen wrote:
> Du (devnull4711) meintest am 07.01.08:
>>> Wie kann ich dem System beibringen, dass es keinen Architekturfehler
>>> bemängelt?
>
>> Sauberer Weg:
>> Das Modul Errno installieren. Die Datei Errno.pm wird passed
>> zum System generiert, da sie systemnahe Fehlercodes enthält.
>
> Hmmm - ich habe auf einigen Maschinen einige Kernel (2.4.x.y und
> 2.6.x.y) installiert: kann perl sich das passende Modul je nach
> Kernelversion heraussuchen?

Nein, ist auch nicht notwendig. Das Linux-Kernel-API ändert sich nie auf
inkompatible Weise.

hp

Re: Kernelversion falsch?

Peter J. Holzer wrote:
> On 2008-01-07 14:44, Helmut Hullen wrote:

>>>>Wie kann ich dem System beibringen, dass es keinen Architekturfehler
>>>>bemängelt?
>>
>>>Sauberer Weg:
>>>Das Modul Errno installieren. Die Datei Errno.pm wird passed
>>>zum System generiert, da sie systemnahe Fehlercodes enthält.
>>
>>Hmmm - ich habe auf einigen Maschinen einige Kernel (2.4.x.y und
>>2.6.x.y) installiert: kann perl sich das passende Modul je nach
>>Kernelversion heraussuchen?
>
> Nein, ist auch nicht notwendig. Das Linux-Kernel-API ändert sich nie auf
> inkompatible Weise.

In Errno.pm wird aber auf die genaue Kernel-Versionsnummer geprüft.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Kernelversion falsch?

On 2008-01-07 16:07, Frank Seitz wrote:
> Peter J. Holzer wrote:
>> On 2008-01-07 14:44, Helmut Hullen wrote:
>
>>>>>Wie kann ich dem System beibringen, dass es keinen Architekturfehler
>>>>>bemängelt?
>>>
>>>>Sauberer Weg:
>>>>Das Modul Errno installieren. Die Datei Errno.pm wird passed
>>>>zum System generiert, da sie systemnahe Fehlercodes enthält.
>>>
>>>Hmmm - ich habe auf einigen Maschinen einige Kernel (2.4.x.y und
>>>2.6.x.y) installiert: kann perl sich das passende Modul je nach
>>>Kernelversion heraussuchen?
>>
>> Nein, ist auch nicht notwendig. Das Linux-Kernel-API ändert sich nie auf
>> inkompatible Weise.
>
> In Errno.pm wird aber auf die genaue Kernel-Versionsnummer geprüft.

Nein. Das widerspricht erstens der von Helmut geposteten Fehlermeldung
(keine der beiden Kernelversionen aus der Meldung entspricht dem Kernel,
den er laufen hat), und zweitens meiner Erfahrung.
Errno hat sich bei mir noch nie über einen Kernel-Upgrade beschwert.
Wäre auch hochgradig unsinnig, wenn man nach jedem Kernel-Upgrade Perl
neu installieren müsste.

Was Errno überprüft, ist, ob die Architektur, unter der das
Perl-Executable gebaut worden ist mit der Architektur übereinstimmt, für
die Errno.pm gebaut wurde:

"$Config{'archname'}-$Config{'osvers'}" eq
"i686-linux-2.6.21" or
die "Errno architecture (i686-linux-2.6.21) does not match executable architecture ($Config{'archname'}-$Config{'osvers'})";

Das ist normalerweise immer der Fall, weil Errno Teil der
Core-Distribution ist und gemeinsam mit dem Executable gebaut und
installiert wird. Nur wenn man z.B. PERL5INC unsinnig setzt, oder Teile
der Perl-Installation austauscht (z.B. /usr/bin/perl auf einen anderen
Rechner kopiert und den Rest gleichläßt) dann passt das nicht mehr
zusammen und Errno beschwert sich.

hp

Re: Kernelversion falsch?

Peter J. Holzer wrote:
> On 2008-01-07 16:07, Frank Seitz wrote:
>>
>>In Errno.pm wird aber auf die genaue Kernel-Versionsnummer geprüft.
>
> Nein. Das widerspricht erstens der von Helmut geposteten Fehlermeldung

Seine Fehlermeldung enthält die Kernel-Versionsnummer: i486-linux-2.4.33.3.

> (keine der beiden Kernelversionen aus der Meldung entspricht dem Kernel,
> den er laufen hat), und zweitens meiner Erfahrung.
> Errno hat sich bei mir noch nie über einen Kernel-Upgrade beschwert.
> Wäre auch hochgradig unsinnig, wenn man nach jedem Kernel-Upgrade Perl
> neu installieren müsste.

Du hast recht, dass die Versionsnummer nicht der Versionsnummer
des laufenden Kernels entsprechen muss. Es ist die Versionsnummer des
Kernels (OS), unter dem die Perl-Installation gebaut wurde.

> Was Errno überprüft, ist, ob die Architektur, unter der das
> Perl-Executable gebaut worden ist mit der Architektur übereinstimmt, für
> die Errno.pm gebaut wurde:
>
> "$Config{'archname'}-$Config{'osvers'}" eq
> "i686-linux-2.6.21" or
> die "Errno architecture (i686-linux-2.6.21) does not match executable architecture ($Config{'archname'}-$Config{'osvers'})";
>
> Das ist normalerweise immer der Fall, weil Errno Teil der
> Core-Distribution ist und gemeinsam mit dem Executable gebaut und
> installiert wird. Nur wenn man z.B. PERL5INC unsinnig setzt, oder Teile
> der Perl-Installation austauscht (z.B. /usr/bin/perl auf einen anderen
> Rechner kopiert und den Rest gleichläßt) dann passt das nicht mehr
> zusammen und Errno beschwert sich.

Ja, irgendsowas macht er wohl

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Kernelversion falsch?

Hallo, Peter,

Du (hjp-usenet2) meintest am 07.01.08:

> "$Config{'archname'}-$Config{'osvers'}" eq
> "i686-linux-2.6.21" or
> die "Errno architecture (i686-linux-2.6.21) does not match
> executable architecture ($Config{'archname'}-$Config{'osvers'})";

> Das ist normalerweise immer der Fall, weil Errno Teil der
> Core-Distribution ist und gemeinsam mit dem Executable gebaut und
> installiert wird. Nur wenn man z.B. PERL5INC unsinnig setzt, oder
> Teile der Perl-Installation austauscht (z.B. /usr/bin/perl auf einen
> anderen Rechner kopiert und den Rest gleichläßt) dann passt das nicht
> mehr zusammen und Errno beschwert sich.

Schön - das scheint hier vorzuliegen. Etliche Module, die schon älter
sind (Kernel 2.4.3x), und jetzt eine neue Perl-Version (Kernel 2.6.x.y).
Und jetzt hakt es.
Muss ich demnach jedes der alten Module neu kompilieren?

Auch "cpan2tgz" hakt jetzt. Mault wegen eines falschen Filedeskriptors.
Und will nicht neu kompilieren (und den Tarball packen), wenn das Modul
schon vorhanden ist (aber noch zum alten Kernel passt).

Gerade (genauer: seit mehr als 1 Stunde) läuft "cpan -r"; mal sehen, ob
damit das Grundsystem nicht mehr muckelt. Aber das erzeugt keine
Tarballs ...

Viele Gruesse!
Helmut

Re: Kernelversion falsch?

Hallo, Frank,

Du (devnull4711) meintest am 07.01.08:

>>> In Errno.pm wird aber auf die genaue Kernel-Versionsnummer geprüft.

>> (keine der beiden Kernelversionen aus der Meldung entspricht dem
>> Kernel, den er laufen hat), und zweitens meiner Erfahrung.
>> Errno hat sich bei mir noch nie über einen Kernel-Upgrade beschwert.
>> Wäre auch hochgradig unsinnig, wenn man nach jedem Kernel-Upgrade
>> Perl neu installieren müsste.

> Du hast recht, dass die Versionsnummer nicht der Versionsnummer
> des laufenden Kernels entsprechen muss. Es ist die Versionsnummer des
> Kernels (OS), unter dem die Perl-Installation gebaut wurde.

Stimmt - die hat offensichtlich nichts mit dem Kernel zu tun, der
aktuell benutzt wird.
Aber das bestätigt ja meine Befürchtung, dass ich bei einem Wechsel der
Perl-Version auch alle (oder wenigsten viele) Module neu kompilieren
muss.

Viele Gruesse!
Helmut

Re: Kernelversion falsch?

Helmut Hullen wrote:
>
> Stimmt - die hat offensichtlich nichts mit dem Kernel zu tun, der
> aktuell benutzt wird.
> Aber das bestätigt ja meine Befürchtung, dass ich bei einem Wechsel der
> Perl-Version auch alle (oder wenigsten viele) Module neu kompilieren
> muss.

Es sollte klar sein, dass du Dinge nicht beliebig mixen kannst,
was du genau vor hast, hast du nicht erzählt.

Hier ist die Beschreibung, wie ein Perl-Upgrade funktioniert,
vielleicht hilft dir das weiter: http://kuerzer.de/perl_upgrade

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Kernelversion falsch?

On 2008-01-07 22:02, Helmut Hullen wrote:
> Du (hjp-usenet2) meintest am 07.01.08:
>> "$Config{'archname'}-$Config{'osvers'}" eq
>> "i686-linux-2.6.21" or
>> die "Errno architecture (i686-linux-2.6.21) does not match
>> executable architecture ($Config{'archname'}-$Config{'osvers'})";
>
>> Das ist normalerweise immer der Fall, weil Errno Teil der
>> Core-Distribution ist und gemeinsam mit dem Executable gebaut und
>> installiert wird. Nur wenn man z.B. PERL5INC unsinnig setzt, oder
^^^^^^^^
PERL5LIB natürlich.
>> Teile der Perl-Installation austauscht (z.B. /usr/bin/perl auf einen
>> anderen Rechner kopiert und den Rest gleichläßt) dann passt das nicht
>> mehr zusammen und Errno beschwert sich.
>
> Schön - das scheint hier vorzuliegen. Etliche Module, die schon älter
> sind (Kernel 2.4.3x), und jetzt eine neue Perl-Version (Kernel 2.6.x.y).

Bei der neuen Perl-Version sollte aber auch ein neues, dazupassendes
Errno.pm dabei sein. Wenn man Perl von Source compiliert und
installiert, ist das sicher der Fall. Wenn der Distributionsmaintainer
(also Du, wenn ich Dich recht verstanden habe[1]) einen Grund sieht,
Errno.pm in ein anderes Package zu geben als das Perl-Executable (mir
fällt da kein plausibler Grund ein, aber es mag einen geben), dann
sollte er über Abhängigkeiten dafür sorgen, dass man nur beides zugleich
updaten kann, aber niemals das eine ohne das andere. (Wenn Deine
Distribution kein vernünftiges Abhängigkeitssystem kennt, solltest Du
sie vielleicht umstellen - RPM und .deb sind weitverbreitete Paketformate,
die das seit langem unterstützen).


> Und jetzt hakt es.
> Muss ich demnach jedes der alten Module neu kompilieren?

Nein, ist im Allgemeinen nicht notwendig. Und Errno ist ein Core-Modul,
das bei Perl dabei ist. Wenn Du Perl neu kompilierst, wird das
automatisch neu erstellt. Da musst Du keinen besonderen Aufwand
hineinstecken, im Gegenteil, Du musst irgendwas Ungewöhnliches machen
(einzelne Files kopieren, PERL5LIB setzen), um das kaputt zu machen.
Also versuch herauszufinden, was Du falsch gemacht hast, anstatt an den
Symptomen herumzudoktern.


> Gerade (genauer: seit mehr als 1 Stunde) läuft "cpan -r"; mal sehen, ob
> damit das Grundsystem nicht mehr muckelt. Aber das erzeugt keine
> Tarballs ...

Irgendwie scheint mir Deine Art, Distributionen zu bauen, reichlich
chaotisch zu sein.


hp

[1] Das ist etwas widersprüchlich: Einerseits schreibst Du "ich betreue
eine Distribution" andererseits ist in dem Thread von Slackware die
Rede, und dessen Maintainer heißt meines Wissens immer noch Patrick
Volkerding und nicht Helmut Hullen.

Re: Kernelversion falsch?

Hallo, Peter,

Du (hjp-usenet2) meintest am 07.01.08:

>> Wie kann ich dem System beibringen, dass es keinen Architekturfehler
>> bemängelt?

> Eine konsistente Distribution bauen bzw. installieren.

Danke - ein sehr hilfreicher Vorschlag.
Kannst Du den bitte ein wenig konkretisieren?

Viele Gruesse!
Helmut

Re: Kernelversion falsch?

Hallo, Peter,

Du (hjp-usenet2) meintest am 08.01.08:

>> Schön - das scheint hier vorzuliegen. Etliche Module, die schon
>> älter sind (Kernel 2.4.3x), und jetzt eine neue Perl-Version (Kernel
>> 2.6.x.y).

> Bei der neuen Perl-Version sollte aber auch ein neues, dazupassendes
> Errno.pm dabei sein. Wenn man Perl von Source compiliert und
> installiert, ist das sicher der Fall. Wenn der
> Distributionsmaintainer (also Du, wenn ich Dich recht verstanden
> habe[1]) einen Grund sieht, Errno.pm in ein anderes Package zu geben
> als das Perl-Executable (mir fällt da kein plausibler Grund ein, aber
> es mag einen geben), dann sollte er über Abhängigkeiten dafür sorgen,
> dass man nur beides zugleich updaten kann, aber niemals das eine ohne
> das andere.

Ich benutze Slackware als Grundlage. Und diese Grundlage ergänze ich
durch einige Module, in Form von Tarballs.

http://arktur.de

Es ist lästig, wenn alle (oder auch nur viele) Module neu kompiliert
werden müssen, nur weil Perl geändert wurde.
Ist m.E. ein grundsätzlicher Fehler bei den Modulen.

Dass so etwas anders geht, zeigt die Verwaltung der Anhängigkeiten beim
Paketmanagement von Linux-Distributionen.

> (Wenn Deine Distribution kein vernünftiges
> Abhängigkeitssystem kennt, solltest Du sie vielleicht umstellen - RPM
> und .deb sind weitverbreitete Paketformate, die das seit langem
> unterstützen).

Die Abhängigkeiten prüfe ich - und dabei bin ich auf das Problem
gestossen. Kannst Du mir bei der Lösung dieses speziellen Problems
helfen?
Der Hinweis auf anderer Distributionen Paketmanagement ist keine
sonderliche Hilfe, sondern nur Verlagerung des Problems. Auch dort
müssen die Abhängigkeiten irgendwann von irgendjemandem ermittelt werden
- so wie ich das jetzt bei den cpan-Modulen machen muss.

> Also versuch herauszufinden, was Du falsch
> gemacht hast, anstatt an den Symptomen herumzudoktern.

Toll - genau das versuche ich.
Kannst Du vielleicht zusätzlich zu den allgemeinen Hinweisen auch
konkrete Hilfen geben?

Viele Gruesse!
Helmut

Re: Kernelversion falsch?

On 2008-01-08 10:01, Helmut Hullen wrote:
> Du (hjp-usenet2) meintest am 08.01.08:
>
>>> Schön - das scheint hier vorzuliegen. Etliche Module, die schon
>>> älter sind (Kernel 2.4.3x), und jetzt eine neue Perl-Version (Kernel
>>> 2.6.x.y).
>
>> Bei der neuen Perl-Version sollte aber auch ein neues, dazupassendes
>> Errno.pm dabei sein. Wenn man Perl von Source compiliert und
>> installiert, ist das sicher der Fall. Wenn der
>> Distributionsmaintainer (also Du, wenn ich Dich recht verstanden
>> habe[1]) einen Grund sieht, Errno.pm in ein anderes Package zu geben
>> als das Perl-Executable (mir fällt da kein plausibler Grund ein, aber
>> es mag einen geben), dann sollte er über Abhängigkeiten dafür sorgen,
>> dass man nur beides zugleich updaten kann, aber niemals das eine ohne
>> das andere.
>
> Ich benutze Slackware als Grundlage. Und diese Grundlage ergänze ich
> durch einige Module, in Form von Tarballs.

Du willst aber nicht ernsthaft behaupten, dass Slackware kein Errno.pm
enthält und Du das daher selber bauen musst? Ich bin zwar vor über 10
Jahren von Slackware zu Redhat gewechselt, weil mich einige Dinge (vor
allem das völlig unzureichende Paketsystem) störten, aber so einen
Lapsus traue ich Slackware doch nicht zu - schon deswegen, weil dieser
Lapsus die bewusste Entscheidung verlangt, Errno wegzulassen, und warum
sollte ein Distributor das tun?


> http://arktur.de
>
> Es ist lästig, wenn alle (oder auch nur viele) Module neu kompiliert
> werden müssen, nur weil Perl geändert wurde.

Das ist wie gesagt nicht der Fall, und schon gar nicht bei Errno, das Du
nie selber extra kompilieren musst, weil es bei Perl einfach dabei ist.

> Ist m.E. ein grundsätzlicher Fehler bei den Modulen.

Nein. Es bestenfalls ein Fehler in der Art, wie Slackware Deine
Perl-Distribution gebaut hat. Sowohl bei Redhat als auch bei Debian
findet sich z.B. ein Directory ohne Versions- und Architekturangabe in
@INC, und Redhat achtet darauf, dass sich die Directories der
Vorversionen in @INC befinden - und zwar in absteigender Reihenfolge,
damit Module für die aktuellere Version vor eventuell übriggebliebenen
älteren Versionen gefunden werden.

> Dass so etwas anders geht, zeigt die Verwaltung der Anhängigkeiten beim
> Paketmanagement von Linux-Distributionen.

Bei allen mir bekannten Linuxdistributionen sind auch die Abhängigkeiten
zwischen Perl und seinen Modulen sowie die Default-Destinations für
selbstinstallierte Sachen zumindest brauchbar. Wie Du Deine
Slackware-Installation vermurkst hast, weiß ich nicht, und das wird auch
keiner feststellen können, solange Du auf konkrete Fragen und Hinweise
nicht eingehst, sondern lieber allgemein dahinjammerst, dass Perl so
Scheiße ist.


>> (Wenn Deine Distribution kein vernünftiges
>> Abhängigkeitssystem kennt, solltest Du sie vielleicht umstellen - RPM
>> und .deb sind weitverbreitete Paketformate, die das seit langem
>> unterstützen).
>
> Die Abhängigkeiten prüfe ich - und dabei bin ich auf das Problem
> gestossen. Kannst Du mir bei der Lösung dieses speziellen Problems
> helfen?

Das könnte ich vielleicht, wenn Du meine Fragen beantworten würdest. Da
Du das aber nicht machst, kann ich es natürlich nicht, weil ich Dein
System nicht kenne.


> Der Hinweis auf anderer Distributionen Paketmanagement ist keine
> sonderliche Hilfe, sondern nur Verlagerung des Problems. Auch dort
> müssen die Abhängigkeiten irgendwann von irgendjemandem ermittelt werden
> - so wie ich das jetzt bei den cpan-Modulen machen muss.

Wenn Du selber Packages erstellst, ist das Deine Aufgabe, ja (wobei es
Tools gibt, die das weitgehend automatisieren). Wenn Dir das zu viel
ist, solltest Du keine Packages erstellen und schon gar keine
Distribution (egal ob from Scratch oder auf einer anderen basierend)
maintainen. Und ja, i.A. ist der Aufwand für den Maintainer höher, wenn
das Package-System ausgefeilter ist - dafür kann der User dann weniger
falsch machen.


>> Also versuch herauszufinden, was Du falsch
>> gemacht hast, anstatt an den Symptomen herumzudoktern.
>
> Toll - genau das versuche ich.

Dann erkläre endlich mal, wie Du es geschafft hast, ein /usr/bin/perl
und ein Errno.pm aufs gleiche System zu bringen, die offensichtlich
nicht zusammenpassen. Auf meine bereits zweimal geäußerten Vermutungen
dazu bist Du bisher mit keinem Wort eingegangen.

> Kannst Du vielleicht zusätzlich zu den allgemeinen Hinweisen auch
> konkrete Hilfen geben?

Meine konkreten Hilfen ignorierst Du ja beharrlich.

hp

Re: Kernelversion falsch?

Hallo, Peter,

Du (hjp-usenet2) meintest am 08.01.08:

>> Ich benutze Slackware als Grundlage. Und diese Grundlage ergänze ich
>> durch einige Module, in Form von Tarballs.

> Du willst aber nicht ernsthaft behaupten, dass Slackware kein
> Errno.pm enthält und Du das daher selber bauen musst?

Das habe ich nicht ernsthaft behauptet.
Die Datei wurde im Zusammenhang mit einer Fehlermeldung erwähnt, und (im
entsprechenden Verzeichnis)

make
make install

hat diesen Fehler beseitigt.

> Ich bin zwar
> vor über 10 Jahren von Slackware zu Redhat gewechselt, weil mich
> einige Dinge (vor allem das völlig unzureichende Paketsystem)
> störten, aber so einen Lapsus traue ich Slackware doch nicht zu -
> schon deswegen, weil dieser Lapsus die bewusste Entscheidung
> verlangt, Errno wegzulassen, und warum sollte ein Distributor das
> tun?

Sorry - das verlangt dieser Lapsus nicht.

> brauchbar. Wie Du Deine Slackware-Installation vermurkst hast, weiß
> ich nicht, und das wird auch keiner feststellen können, solange Du
> auf konkrete Fragen und Hinweise nicht eingehst, sondern lieber
> allgemein dahinjammerst, dass Perl so Scheiße ist.

Sorry - ich habe nirgendwo "dahingejammert", dass "Perl so Scheiße" sei.
Unterstelle mir bitte nichts, was Du frei erfunden hast.

>> Der Hinweis auf anderer Distributionen Paketmanagement ist keine
>> sonderliche Hilfe, sondern nur Verlagerung des Problems. Auch dort
>> müssen die Abhängigkeiten irgendwann von irgendjemandem ermittelt
>> werden - so wie ich das jetzt bei den cpan-Modulen machen muss.

> Wenn Du selber Packages erstellst, ist das Deine Aufgabe, ja (wobei
> es Tools gibt, die das weitgehend automatisieren).

So isses.

> Wenn Dir das zu viel ist, solltest Du keine Packages erstellen und
> schon gar keine Distribution (egal ob from Scratch oder auf einer
> anderen basierend) maintainen.

Du kommst schon wieder mit diffusen Vermutungen und Unterstellungen. Mag
ja schön für Dich sein, aber damit drückst Du Dich nur vor konkreten
Hilfen.

Woraus schliesst Du beispielsweise, dass mir irgendwas zu viel sei?
Wilde Vermutungen.

>>> Also versuch herauszufinden, was Du falsch
>>> gemacht hast, anstatt an den Symptomen herumzudoktern.
>>
>> Toll - genau das versuche ich.

> Dann erkläre endlich mal, wie Du es geschafft hast, ein /usr/bin/perl
> und ein Errno.pm aufs gleiche System zu bringen, die offensichtlich
> nicht zusammenpassen.

Durch Installation des Slackware-Perl-Pakets (inzwischen wieder das
Paket von Slackware 11.0). Wobei ich nicht weiss, ob die Teile (alle aus
dem gleichen Paket) nicht zusammenpassen; ich weiss nur, dass
"mimedefang" damit nicht zurechtkommt.

> Auf meine bereits zweimal geäußerten
> Vermutungen dazu bist Du bisher mit keinem Wort eingegangen.

Weil das "seltsame" Vermutungen waren. Eher abstruse Unterstellungen.
Auf der Basis können wir uns natürlich weiter unterhalten, aber das
dürfte m.E. nicht zur Problemlösung führen.

>> Kannst Du vielleicht zusätzlich zu den allgemeinen Hinweisen auch
>> konkrete Hilfen geben?

> Meine konkreten Hilfen ignorierst Du ja beharrlich.

Das sind Unterstellungen gewesen. Und Hinweise, dass irgendwo irgendwas
anders gemacht wird. Nicht so recht konkret.
Insbesondere die Hinweise auf Paketverwaltungen anderer Distributionen
sind zwar in sich richtig, aber nicht "zielführend".

Viele Gruesse!
Helmut

Re: Kernelversion falsch?

Helmut Hullen wrote:
>
> [...] aber damit drückst Du Dich nur vor konkreten Hilfen.

Diese NG ist kein Debugging-Service.

Wenn du möchtest, dass man dir hier weiter hilft, was in jedem
Fall auf freiwilliger Basis geschieht, solltest du erst mal
halbwegs klar beschreiben, was du vor hast, wie du dieses
Ziel bislang zu erreichen versucht hast und an welcher
Stelle genau du gescheitert bist. Bislang hast du hier eher
komische Selbstgespräche abgeliefert.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Kernelversion falsch?

Hallo, Frank,

Du (devnull4711) meintest am 08.01.08:

>> [...] aber damit drückst Du Dich nur vor konkreten Hilfen.

> Diese NG ist kein Debugging-Service.

Weiss ich - ich lese und schreibe in einigen anderen Newsgroups und
Mailinglisten mit.

> Wenn du möchtest, dass man dir hier weiter hilft, was in jedem
> Fall auf freiwilliger Basis geschieht, solltest du erst mal
> halbwegs klar beschreiben, was du vor hast, wie du dieses
> Ziel bislang zu erreichen versucht hast und an welcher
> Stelle genau du gescheitert bist. Bislang hast du hier eher
> komische Selbstgespräche abgeliefert.

"Am Anfang schuf ich Himmel und Erde ..."

Ich betreue seit vielen Jahren eine Schulserver-Distribution und packe
dort seit vielen Jahren cpan-Module mit auf die CD, die ich per
"cpan2tgz" erzeugen lasse.
Denn beim Perl-Pake wird (selbstverständlich) nicht jedes Modul
mitgeliefert.

Und ich mag den Endbenutzern nicht zumuten, dass jeder erst mal einige
Dutzend cpan-Module nachkompiliert.

Beispiel "iwatch":
Die Module Event, Linux::Inotify2, Mail::Sendmail und 3 XML-Module
müssen nachgeliefert werden.


Beispiel "mimedefang":

Die Module MIME::Tools, Digest::SHA1, IO::Stringy und mailtools müssen
nachgeliefert werden, und das scheint noch nicht zu reichen:

"mimedefang.pl -features" liefert

MIMEDefang version 2.56

Path:CONFDIR : yes (/etc/mimedefang)
Path:QUARANTINEDIR : yes (/var/spool/MD-Quarantine)
Path:SENDMAIL : yes (/usr/sbin/sendmail)
Path:SPOOLDIR : yes (/var/spool/MIMEDefang)
Virus:BDC : yes (/usr/bin/bdc)
AutoDetectPerlModules : no
Unix::Syslog : no
Virus:AVP : no
Virus:AVP5 : no
Virus:CSAV : no
Virus:FPROTD : no
Virus:FSAV : no
Virus:FileScan : no
Virus:HBEDV : no
Virus:KAVSCANNER : no
Virus:NVCC : no
Virus:OpenAV : no
Virus:SOPHIE : no
Virus:SOPHOS : no
Virus:SymantecCSS : no
Virus:TREND : no
Virus:TROPHIE : no
Virus:VEXIRA : no

Anomy::HTMLCleaner : missing
Archive::Zip : missing
Digest::SHA1 : Version 2.11
File::Scan : missing
HTML::Parser : missing
HTML::TokeParser : missing
IO::Socket : Version 1.29
IO::Stringy : Version 2.110
MIME::Base64 : Version 3.07
MIME::Tools : Version 5.423
MIME::Words : Version 5.423
Mail::Mailer : Version 1.74
Mail::SpamAssassin : missing
Net::DNS : missing
Unix::Syslog : missing

Bei den hier mit "missing" vermerkten Modulen vermute ich, dass ich sie
auch nachinstallieren muss - ich habe das mal mit einer Installation
ausprobiert, bei der einzig das perl-5.8.8-Paket von Slackware vorlag.

---------------

Mit den zusätzlich (von mir) kompilierten und als Tarball verpackten
weiteren Modulen hat alles einige Jahre brav funktioniert.

Problem 1: Slackware 12.0 hat perl mit der Option "thread-multi"
kompiliert - da wurde anscheinend keines der Module akzeptiert.

Problem 2: "Errno.pm" wurde bemängelt (wie ich erwähnt hatte);
nachkompilieren hat das Problem behoben (wie ich erwähnt hatte).

Möglicher Auslöser: "cpan2tgz" hat mir auch ein Paket "perl-errno-
xxx.tgz" erzeugt, das ich auch nachinstalliert habe. Es könnte sein,
dass ich dieses Paket aus der Sammlung herausnehmen muss - in den
nächsten Tagen werde ich weiter testen.

Brauchst Du noch mehr Informationen?

------------

Ach ja: "cpan" und "cpan2tgz" haben anscheinend Probleme, wenn sie auf
einem Rechner hinter einem Server sitzen - die "proxy"-Einstellung wird
anscheinend nicht jederzeit berücksichtigt.

Viele Gruesse!
Helmut

Re: Kernelversion falsch?

Helmut Hullen wrote:

> Mit den zusätzlich (von mir) kompilierten und als Tarball verpackten
> weiteren Modulen hat alles einige Jahre brav funktioniert.
>
> Problem 1: Slackware 12.0 hat perl mit der Option "thread-multi"
> kompiliert - da wurde anscheinend keines der Module akzeptiert.

Alle Module mit XS-Anteil musst du neu bauen, sprich: auspacken
und rekompilieren, die anderen nicht (siehe Link, den ich gepostet hatte).

> Problem 2: "Errno.pm" wurde bemängelt (wie ich erwähnt hatte);
> nachkompilieren hat das Problem behoben (wie ich erwähnt hatte).
>
> Möglicher Auslöser: "cpan2tgz" hat mir auch ein Paket "perl-errno-
> xxx.tgz" erzeugt, das ich auch nachinstalliert habe. Es könnte sein,
> dass ich dieses Paket aus der Sammlung herausnehmen muss - in den
> nächsten Tagen werde ich weiter testen.

Warum holst du die Sachen neu von CPAN? Hast du von Deinen
Perl-Paketen die Quellen nicht aufgehoben?

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Kernelversion falsch?

Hallo, Frank,

Du (devnull4711) meintest am 09.01.08:

>> Problem 1: Slackware 12.0 hat perl mit der Option "thread-multi"
>> kompiliert - da wurde anscheinend keines der Module akzeptiert.

> Alle Module mit XS-Anteil musst du neu bauen, sprich: auspacken
> und rekompilieren, die anderen nicht (siehe Link, den ich gepostet
> hatte).

Sorry - das ist zu fachchinesisch für mich: woran erkenne ich "XS-
Anteil"?

Ich habe mal nach Dateien mit "xs" und "XS" im Namen suchen lassen: nur
"perl-xsloader" wurde angezeigt.
Bedeutet das, dass ich kein solches XS-Modul habe?

>> Möglicher Auslöser: "cpan2tgz" hat mir auch ein Paket "perl-errno-
>> xxx.tgz" erzeugt, das ich auch nachinstalliert habe. Es könnte sein,
>> dass ich dieses Paket aus der Sammlung herausnehmen muss - in den
>> nächsten Tagen werde ich weiter testen.

> Warum holst du die Sachen neu von CPAN? Hast du von Deinen
> Perl-Paketen die Quellen nicht aufgehoben?

Vor allem Faulheit: "cpan2tgz" läuft automatisch ab. Bei insgesamt ca.
100 Paketen ist das keine hohe Belastung (und ich habe eine schnelle
Anbindung).
Am Rande: ich habe jetzt mal auf die Installations-CD von SuSE 10.3
geschaut: da werden 210 cpan-Module mitgeliefert, zusätzlich zu dem, was
im Perl-Paket selbst drin ist.

Viele Gruesse!
Helmut

Re: Kernelversion falsch?

"Helmut Hullen":

> Sorry - das ist zu fachchinesisch für mich: woran erkenne ich "XS-
> Anteil"?

XS-Module sind solche, die neben Perl-Code auch kompilierten C-Code
verwenden. Sie bestehen daher aus zumindest zwei Dateien: der .pm-Datei
und (unter Linux) einer .so-Datei. Letzere wird von ersterer mit Hilfe eines
Moduls namens DynaLoader (oder seines jüngeren "Bruders" XSLoader)
beim Laden des Moduls ("use ") eingebunden.

Enthält die .pm-Datei einen "bootstrap" (DynaLoader) oder einen
"XSLoader::load" (XSLoader) Aufruf, dann handelt es sich um ein Modul
mit XS-Anteil.

XS-Code jongliert meist mit internen Strukturen, die von Version zu
Version, aber auch von Perltyp zu Perltyp (z.B. threaded Perl vs. non-
threaded Perl) unterschiedlich sind. Daher kann es bei einem Versions-
wechsel oder beim händischem Kopieren zwischen gleichen Versionen,
aber unterschiedlichen Perltypen Probleme geben. Guter XS-Code
erkennt das und gibt eine Fehlermeldung aus, ansosten ist bis zum einem
Coredump alles möglich.

In den Perl Release Notes findet sich oft der Hinweis "This version is
NOT binary-compatible with any previous versions" oder etwas in der
Art. Das sagt dir dann, dass du XS-Module, die nicht mit der neuen
Version mitgeliefert werden, neu kompilieren musst; du darfst die
Moduldateien (vor allem die .so-Datei) nicht einfach vom alten in den
neuen Library-Tree kopieren.

> Ich habe mal nach Dateien mit "xs" und "XS" im Namen suchen lassen: nur
> "perl-xsloader" wurde angezeigt.
> Bedeutet das, dass ich kein solches XS-Modul habe?

Oja, ganz bestimmt. Viele Module der Core-Distribution besitzen einen
XS-Anteil: B, Devel::Peek, List::Util, Cwd, Socket, File::Glob, threads,
Fcntl, POSIX, IO und attributes, um nur einige der Bekannteren zu
nennen (letzteres ist übrigens ein Sonderfall, da sein XS-Anteil bereits
im Perl-Core enthalten ist und mittels "bootstrap" nur noch aktiviert
wird).

HTH & LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolhar-nordenkampf@wien.gv.at

Re: Kernelversion falsch?

Helmut Hullen wrote:
>
> Sorry - das ist zu fachchinesisch für mich: woran erkenne ich "XS-
> Anteil"?

XS-Module installieren sich in ein Verzeichnis mit $archname (z.B. i486-linux):

/$prefix/lib/perl5/$version/$archname (Core Module)
/$prefix/lib/perl5/site_perl/$version/$archname (nachinstallierte Module)

> Ich habe mal nach Dateien mit "xs" und "XS" im Namen suchen lassen: nur
> "perl-xsloader" wurde angezeigt.
> Bedeutet das, dass ich kein solches XS-Modul habe?

Nein. Gucke in die o.g. Verzeichnisse. Für dich dürfte nur
letzeres interessant sein.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Kernelversion falsch?

Hallo, Ferry,

Du (bol) meintest am 09.01.08:

>> Ich habe mal nach Dateien mit "xs" und "XS" im Namen suchen lassen:
>> nur "perl-xsloader" wurde angezeigt.
>> Bedeutet das, dass ich kein solches XS-Modul habe?

> Oja, ganz bestimmt. Viele Module der Core-Distribution besitzen einen
> XS-Anteil: B, Devel::Peek, List::Util, Cwd, Socket, File::Glob,
> threads, Fcntl, POSIX, IO und attributes, um nur einige der
> Bekannteren zu nennen (letzteres ist übrigens ein Sonderfall, da sein
> XS-Anteil bereits im Perl-Core enthalten ist und mittels "bootstrap"
> nur noch aktiviert wird).

In "/usr/lib/perl5/5.8.8/i486-linux/File/Glob.pm" habe ich

use XSloader ();

gefunden, aber keine *.so-Datei.

Die Suche nach *.so unterhalb von "perl5" brachte etliche (andere)
Treffer (u.a. Event.so).

Ist die "use XSloader"-Zeile wichtig? Oder reicht die Suche nach *.so?

Ich brauche keine absolute Sicherheit (obwohl die natürlich schön wäre);
95% reicht mir schon ...

Viele Gruesse!
Helmut

Re: Kernelversion falsch?

Hallo, Frank,

Du (devnull4711) meintest am 09.01.08:

>> Sorry - das ist zu fachchinesisch für mich: woran erkenne ich "XS-
>> Anteil"?

> XS-Module installieren sich in ein Verzeichnis mit $archname (z.B.
> i486-linux):

> /$prefix/lib/perl5/$version/$archname (Core Module)
> /$prefix/lib/perl5/site_perl/$version/$archname (nachinstallierte
> Module)

Gut - da ist erst mal handlich, und meine Suche nach *.so hat nur in
diesen Verzeichnissen (genauer: .../i486-linux/auto/) was gefunden.

Allerdings sind da auch etliche Module ohne eine einzige *.so-Datei:
müssen die nicht neu kompiliert werden?


Viele Gruesse!
Helmut

Re: Kernelversion falsch?

Helmut Hullen wrote:
> Du (devnull4711) meintest am 09.01.08:
>>
>>XS-Module installieren sich in ein Verzeichnis mit $archname (z.B.
>>i486-linux):
>>
>> /$prefix/lib/perl5/$version/$archname (Core Module)
>> /$prefix/lib/perl5/site_perl/$version/$archname (nachinstallierte
>>Module)
>
> Gut - da ist erst mal handlich, und meine Suche nach *.so hat nur in
> diesen Verzeichnissen (genauer: .../i486-linux/auto/) was gefunden.
>
> Allerdings sind da auch etliche Module ohne eine einzige *.so-Datei:
> müssen die nicht neu kompiliert werden?

Ein CPAN-Modul kann mehrere .pm-Dateien enthalten. Der C-Code des Moduls
(wenn es ein XS-Modul ist) wird üblicherweise zu einer einzigen dynamischen
Bibliothek (unter Unix .so-Datei) kompiliert. Alles zusammen wird
bei der Installation dann nach .../$archname getan. Wenn du aus der
Installation auf die CPAN-Module zurückschließen willst, musst du schon
ein bisschen Intuition mitbringen. Faustregel: Je .so-Datei ein Modul.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Kernelversion falsch?

Hallo, Frank,

Du (devnull4711) meintest am 10.01.08:

>> Gut - da ist erst mal handlich, und meine Suche nach *.so hat nur in
>> diesen Verzeichnissen (genauer: .../i486-linux/auto/) was gefunden.

[...]

> Wenn du aus der Installation auf die CPAN-Module
> zurückschließen willst, musst du schon ein bisschen Intuition
> mitbringen. Faustregel: Je .so-Datei ein Modul.

Gut - das lässt sich so einigermassen systematisieren. Danke!

Viele Gruesse!
Helmut

Re: Kernelversion falsch?

"Helmut Hullen":

> In "/usr/lib/perl5/5.8.8/i486-linux/File/Glob.pm" habe ich
>
> use XSloader ();
>
> gefunden, aber keine *.so-Datei.

Die .so Dateien befinden sich stets unterhalb der .pm Datei in
einem 'auto' - Verzeichnis, das seinerseits noch ein Verzeichnis
für jedes Modul enthält, also z.B. für Glob (auf meiner Kiste
mit Redhat Fedora):

/usr/lib/perl5/5.8.6/i386-linux-thread-multi/File/Glob.pm
/usr/lib/perl5/5.8.6/i386-linux-thread-multi/auto/File/Glob/ Glob.so

Unter Windows ist es übrigens ähnlich, nur dass die .so-Dateien
dort eine .dll Endung besitzen:

C:\Perl\lib\File\Glob.pm
C:\Perl\lib\auto\File\Glob\Glob.dll

Allgemein gilt also: Befindet sich die Datei .pm im
Verzeichnis

Re: Kernelversion falsch?

Hallo, Ferry,

Du (bol) meintest am 10.01.08:

> XS-Module befinden sich übrigens _immer_ in einem architektur-
> spezifischen Tree (im obigen Beispiel "i386-linux-thread-multi"),
> da ihre .so Dateien genau für diese Architektur kompiliert wurden.

Danke - dann habe ich das richtig vermutet. Und es ähnelt dem Verfahren,
mit dem bei "Binaries" die jeweilige Architektur angegeben wird; das
sind genug Brücken für Esel ...

> Wie gesagt gibt es allerdings auch noch den älteren DynaLoader,
> den vor allem viele Module, die vor Perl 5.8 erstellt (da wurde
> XSLoader eingeführt) und noch nicht umgestellt wurden, verwenden.

Trifft zum Glück für das, was ich betreue, nicht zu.
(Glaube ich jedenfalls ...)

(Nachtrag: mit Deiner Such-Zeile: 28 Treffer für "DynaLoader" - soviel
zu Glaubensfragen)

> Oft wird übrigens auch statt "use" ein "require" verwendet. Unter
> Linux solltest du aber mit dem Befehlen (unter der bash):

> find /usr/lib/perl5 -name '*.pm' \
> -exec grep -lE '(use|require) +(Dyna|XS)Loader' {} \;

> bzw.

> find /usr/lib/perl5 -name '*.so'

> alle XS-Module aufspüren können. Im Idealfall erhältst du in
> beiden Fällen dieselbe Anzahl an Dateien. ;-))

Danke - schönes weiteres Spielzeug ...
Obere Abfrage: 65 Treffer; untere Abfrage: 60 Treffer.

Die Untersuchung der Unterschiede ist eine reizvolle Aufgabe!

Viele Gruesse!
Helmut

Re: Kernelversion falsch?

"Helmut Hullen":

> Danke - schönes weiteres Spielzeug ...
> Obere Abfrage: 65 Treffer; untere Abfrage: 60 Treffer.
>
> Die Untersuchung der Unterschiede ist eine reizvolle Aufgabe!

Möglicherweise ist der reguläre Ausdruck nicht allgemein genug
oder auch zu ungenau.

So kann man, da "require" ja eine Laufzeitanweisung ist, z.B.
auch

require "DynaLoader.pm"; bzw.
require "XSLoader.pm";

schreiben, was durch meine Regex nicht gefunden würde.

Es kann umgekehrt auch vorkommen, dass die obigen Anweisungen
nur als Kommentare, z.B.

# ... und wird mit "use XSLoader" eingebunden...

im Text aufscheinen. Die werden dann natürlich auch gefunden,
obwohl es keine Ladeanweisungen sind.

Und manche Module besitzen zwar einen XS-Teil, aber dieser
ist optional, d.h., die Funktionalität des Moduls (oder ein Teil
davon) ist auch in Perl implementiert. Wurde der XS-Teil installiert,
wird er beim Laden des Moduls ebenfalls geladen, ansonsten wird
der (meist langsamere) Perl-Code verwendet. Hier steht die
"require"-Anweisung dann in einem if- oder eval-Block. Hast du
den XS-Teil nicht installiert, wird das Modul trotzdem mit der
ersten Abfrage ausgegeben, obwohl es keine .so-Datei dazu
gibt, daher liefert die zweite Abfrage ein unterschiedliches Ergebnis.

Der langen Rede kurzer Sinn: sicher kannst du nur sein, wenn
du für ein Modul bei beiden Abfragen eine Ausgabe erhälst.

LG, Ferry
--