(Linux) sh: make: command not found ?!?

[Dirk]

hallo,

zu allererst möchte ich erwähnen, daß ich absoluter linux-anfänger bin. ich habe einen dediz. server, auf dem Suse Linux 7.2 läuft und als webinterface webmin 0.960.

da der server vorkonfiguriert war, lief soweit auch alles einwandfrei, ohne daß ich größere änderungen vornehmen mußte. jetzt wollte ich jedoch ein perl-modul installieren, und beim kompilieren (was genau heißt eigentlich kompilieren?) tritt folgender fehler auf: sh: make: command not found
wenn ich das ganze nicht über webmin, sondern über die kommandozeile mache, passiert dasselbe. root-rechte habe ich.

kann mir da jemend helfen?

gruß,

Dirk

[Manfred]

Hi!
Versuchs doch erstmal mit ./configure
das erstellt dasnn das Makefile. Also danach make und danach make install
aber meist ist in dem entpackten auch eine Readme dabei wo alles haarklein beschrieben ist.

gruß Manfred

[Alexander Foken]

Moin Moin !

Hi!
Versuchs doch erstmal mit ./configure
das erstellt dasnn das Makefile. Also danach make und danach make install
aber meist ist in dem entpackten auch eine Readme dabei wo alles haarklein beschrieben ist.

gruß Manfred

Sorry, das ist bei der Fehlermeldung Quatsch.

Die Shell (sh) findet das Programm make nicht, wahrscheinlich ist es einfach nicht installiert.

Also SuSEs Config-Programm aufrufen, CD/DVD einlegen oder Pakete aus dem Netz nachinstallieren. Wenn die Kiste beim Provider steht, ist vorher erstmal die Support-Hotline vom Provider dran.

Alexander

[Michael Schröpl]

Hallo Alexander,

Die Shell (sh) findet das Programm make nicht,

yep. Was genau steht in der Environment-Variable PATH dieser Shell?
("echo $PATH")

wahrscheinlich ist es einfach nicht installiert.

Also _das_ würde ich bei Linux _nicht_ als "wahrscheinlich" ansehen.

Viele Grüße
      Michael

[Dirk]

hallo michael,

yep. Was genau steht in der Environment-Variable PATH dieser Shell?
("echo $PATH")

öhm...schlicht + ergreifend: NIX! die variable ist leer. und nun?

gruß, Dirk

[Michael Schröpl]

Hi Dirk,

yep. Was genau steht in der Environment-Variable PATH dieser Shell?
("echo $PATH")
öhm...schlicht + ergreifend: NIX! die variable ist leer.

Tja, schade eigentlich. Denn dort sollte die Liste aller Verzeichnisse
stehen, in denen die Shell nach Kommandos sucht.

Mit einem leeren $PATH sollte allerdings _kein_ Kommando funktionieren
... nicht nur kein "make", sondern auch kein "ls".

Umgekehrt würde _mit_ gesetztem $PATH das Kommando "which" zu einem
Kommando den zugehörigen Pfad liefern.
("which which" -> /usr/bin/which)

und nun?

Mit "find / -name make -ls" nach der Datei suchen und sie ggf. über
ihren absoluten Pfadnamen ansprechen.

Oder (besser) die Konfiguration der Shell reparieren.
(Im Heimatverzeichnis Deiner Benutzerkennung dürfte eine entsprechende
Datei liegen, deren Name mit "." beginnt und mit "rc" endet - der Teil
dazwischen hängt von der verwendeten Shell ab.)

Viele Grüße
      Michael

[Dirk]

hi michael,

Mit einem leeren $PATH sollte allerdings _kein_ Kommando funktionieren
... nicht nur kein "make", sondern auch kein "ls".

doch, das funktioniert.

Mit "find / -name make -ls" nach der Datei suchen und sie ggf. über
ihren absoluten Pfadnamen ansprechen.

es wurde kein make gefunden. dann ist das wohl nicht installiert, oder?

Oder (besser) die Konfiguration der Shell reparieren.
(Im Heimatverzeichnis Deiner Benutzerkennung dürfte eine entsprechende
Datei liegen, deren Name mit "." beginnt und mit "rc" endet - der Teil
dazwischen hängt von der verwendeten Shell ab.)

dort liegen ".exrc" und ".xinitrc". aber ich gehe mal davon aus, daß die shell in ordnung ist, weil andere befehle ja funktionieren. aber ich werde wohl doch eher die hotline meines providers bemühen, denn der server sollte ja "vorkonfiguriert" sein und man könne "problemlos software installieren". wie anfangs erwähnt, gehen meine linux-kenntnise gegen null, und an windoof-maschinen, mit denen ich mich bestens auskenne, hab ich gelernt, besser nix zu machen, wenn man nicht GENAU weiß, WAS man macht...zumal die maschine nicht in meiner reichweite steht.

gruß, Dirk

[Michael Schröpl]

Hi Dirk,

Mit einem leeren $PATH sollte allerdings _kein_ Kommando funktionieren
... nicht nur kein "make", sondern auch kein "ls".
doch, das funktioniert.

Aha. Daß Environment-Variablen case-sensitiv sind,
weißt Du? (PATH ist nicht gleich path!)

Mit "find / -name make -ls" nach der Datei suchen und sie ggf. über
ihren absoluten Pfadnamen ansprechen.
es wurde kein make gefunden. dann ist das wohl nicht
installiert, oder?

Tja, was nicht wahrscheinlich ist, kann dennoch möglich
sein. :-(
Ich dachte bisher, Linux sei ein richtiges UNIX (mit
den von Dir zitierten Eigenschaften) - SuSE scheint
nicht (mehr?) unserer Ansicht zu sein. Sehr schade.
Ein ANSI-C-Compiler und ein GNUmake sind für die
Installation weiterer Software unverzichtbar - beides
wird von vielen Installationsmechanismen unter *N*X
vorausgesetzt (wie Du ja gerade erlebt hast).

dort liegen ".exrc" und ".xinitrc". aber ich gehe mal davon
aus, daß die shell in ordnung ist, weil andere befehle ja
funktionieren.

Yep - diesen Zweig können wir schließen.

aber ich werde wohl doch eher die hotline meines providers
bemühen, denn der server sollte ja "vorkonfiguriert" sein
und man könne "problemlos software installieren".

Es sieht inzwischen deutlich danach aus, als sei Dein
Problem kein Linux-Problem, sondern doch ein "SuSE 7.2
in dieser konkreten Installation"-Problem.

Die Aussage des Herstellers _kann_ sicht durchaus
darauf auf Software beschränken, welche dem bei SuSE
mitgelieferten Installationskonzept entspricht.
(Sie wäre dann zwar sinnlos, aber nicht falsch ...)

Also: SuSE-Installationsverfahren verstehen, passendes
Paket identifizieren und "make" nachinstallieren.

Hast Du schon ein "gcc"? Ich kann mir gut vorstellen,
daß beides in einem gemeinsamen Paket zu installieren,
also "make" Bestandteil des "C-Compiler-Pakets" ist.
(Ich rate aber zugegebenermaßen wild herum ...)

wie anfangs erwähnt, gehen meine linux-kenntnise gegen
null, und an windoof-maschinen, mit denen ich mich bestens
auskenne, hab ich gelernt, besser nix zu machen, wenn man
nicht GENAU weiß, WAS man macht...zumal die maschine nicht
in meiner reichweite steht.

Ein Suse-7.2-Kenner wird Dir sicherlich sagen können,
mit welchem Kommando Du die installierten Pakete
auflisten kannst und in welchem Paket GNUmake mit
drin wäre. Ich bin leider keiner ... aber gemäß der
Vorgabe von SuSE sollte dies in der Tat nicht wirklich
schwer sein.
Und die Chance, dabei etwas kaputt zu machen, ist bei
Linux m. E. deutlich kleiner als bei Windows mit dessen
intransparenter Registry und dem vermurksten DLL-
Konzept ... unter *N*X braucht man kaum gemeinsame
Dateien zu überbügeln, weil man statt dessen über
entsprechende PATH-Definitionen pro Prozeß angeben
kann, auf welche Instanz einer Datei man zugreifen
möchte. Also: Nur Mut!

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo,

Mit einem leeren $PATH sollte allerdings _kein_ Kommando funktionieren

Wenn als root $PATH leer ist, bedeutet das meist, das jemand einfach nur 'su root' ausgeführt hat statt
'su -l root'
(Denk dran, daß Du normalerweise auch nur im /root Verzeichnis bauen kannst)

... nicht nur kein "make", sondern auch kein "ls".

'ls' kann ein Shellbuiltin sein.

Mit "find / -name make -ls" nach der Datei suchen und sie ggf. über
ihren absoluten Pfadnamen ansprechen.
es wurde kein make gefunden. dann ist das wohl nicht
installiert, oder?

Nein, wurde nicht gefunden, da $PATH nicht gesetzt ist.
Kannst Du z.B. mit vollständigem Pfad aufrufen oder richtig als root einloggen, s.o.

Tja, was nicht wahrscheinlich ist, kann dennoch möglich
sein. :-(
Ich dachte bisher, Linux sei ein richtiges UNIX (mit
den von Dir zitierten Eigenschaften) - SuSE scheint
nicht (mehr?) unserer Ansicht zu sein. Sehr schade.

Na, ganz so schlimm ist es nicht.
Aber schlimm ist es wirklich ;-)

Ein ANSI-C-Compiler und ein GNUmake sind für die
Installation weiterer Software unverzichtbar - beides
wird von vielen Installationsmechanismen unter *N*X
vorausgesetzt (wie Du ja gerade erlebt hast).

Es gibt da auch noch eine Minimalinstallation aber in der Standardinstall. ist es natürlich drin.
Selbst bei der Suse ;-)

dort liegen ".exrc" und ".xinitrc". aber ich gehe mal davon
aus, daß die shell in ordnung ist, weil andere befehle ja
funktionieren.

Yep - diesen Zweig können wir schließen.

Insbesondere als Anfänger _und_ root ;-)

Es sieht inzwischen deutlich danach aus, als sei Dein
Problem kein Linux-Problem, sondern doch ein "SuSE 7.2
in dieser konkreten Installation"-Problem.

Kann immer noch ein Bedienungsfehler sein.

Für die Suse 7.2 siehts übrigens mau aus mit Support.
Aktuell ist 8.1, selbst für die 8.0 läuft demnächst der Support aus.

wie anfangs erwähnt, gehen meine linux-kenntnise gegen
null, und an windoof-maschinen, mit denen ich mich bestens
auskenne, hab ich gelernt, besser nix zu machen, wenn man
nicht GENAU weiß, WAS man macht...zumal die maschine nicht
in meiner reichweite steht.

Das ist auch bei Unix keineswegs falsch!
Eher sogar noch wichtiger, denn bei Unix kommen in den seltensten Fällen irgendwelche Nachfragen a la "Sie versuchen gerade den komplette Baum zu löschen! Fortfahren mit 'rm -rfv *'?".

Und die Chance, dabei etwas kaputt zu machen, ist bei
Linux m. E. deutlich kleiner als bei Windows mit dessen
intransparenter Registry und dem vermurksten DLL-
Konzept ... unter *N*X braucht man kaum gemeinsame
Dateien zu überbügeln, weil man statt dessen über
entsprechende PATH-Definitionen pro Prozeß angeben
kann, auf welche Instanz einer Datei man zugreifen
möchte. Also: Nur Mut!

Naja, das mit dem LDE_PRELOAD uns LD_LIBRARYPATH ist nun nicht gerade etwas für Anfänger.
Auch wenn ich das als Entwickler sehr zu schätzen weiß.

so short

Christoph Zurnieden