Danke.
Ursache des Problems: Ich habe ein 64bit Linux und lasse dort eine 32bit Windows-Executable per Wine laufen. Allerdings ist der Wine-Loader ja 64bit und das preloaden von 32bit Bibliotheken klappt natürlich nicht. Sobald dann die "richtige" 32bit-Executable geladen ist, klappt das preloaden.
Hallo.
Danke für die Antworten aber wir haben schon rausgefunden, dass es eine Art Bug auf Fedora ist. Auf zwei anderen Distributionen funktioniert es wie es soll.
Hier gibts mehr Informationen dazu:
http://stackoverflow.com/questions/11050693/dlclose-doesnt-work-with-factory-function-complex-static-in-function
http://www.redhat.com/archives/posix-c++-wg/2009-August/msg00002.html
Ich hab nochmal recherchiert und herausgefunden dass pthread_kill intern tgkill() benutzt. Ich hab dann auch in meinem code eine stelle entdeckt, bei der unter umständen pthread_kill mit einer ungültigen ID aufgerufen wird. Hab den fehler jetzt behoben und hoffe dass es daran lag. Ansonsten werde werde ich mal die lösung von deinem zweiten link ausprobieren, da ich in den logs nichts finden konnte.
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum C (C89 und C99) in das Forum Linux/Unix verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.
Komische Frage eigentlich. Wäre doch viel einfacher, das ganze gleich selbst auszuprobieren. Und wenn man schon mal dabei ist, kann man auch gleich mal gucken, obs auch auf Solaris oder anderen Unixen läuft.
Ansonsten vielleicht zum Programm sowas dabei schreiben wie "läuft optimal unter Debian-Systemen" oder eben "Programm ist optimiert für Debian" oder so ähnlich
Rein richtungsmäßig wäre es vielleicht eher sinnvoller auf Red Hat zu entwickelen und gucken, obs auch auf Debian läuft, Debian hat eben die größere (und ältere) Fangemeinde (Bibpflege usw.).
mlgRs schrieb:
but thanks for your fast reply.. i will try the fork() command to solve the problem
No! You should try to get rid of all those detours first! I do not know the solution because I don't do web development, but I am sure there must be a much better way to do this.
Man sollte ja eigentlich keine vollständigen Lösungen liefern, aber ich bin ja kein Pädagoge und daher weiß ich das ja nicht. Also hier ist ein Beispiel:
#include <iostream>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <errno.h>
#include <string.h>
int main(int argc, char* argv[])
{
if (argc <= 1)
{
std::cerr << "usage: " << argv[0] << " process" << std::endl;
return 1;
}
pid_t pid = fork();
if (pid < 0)
{
std::cerr << "fork failed with errno " << errno << ": " << strerror(errno) << std::endl;
return 1;
}
if (pid != 0)
{
// parent
int status;
wait(&status);
std::cout << "return code: "<< WEXITSTATUS(status) << std::endl;
}
else
{
// child
execvp(argv[1], argv+1);
std::cerr << "exec failed with errno " << errno << ": " << strerror(errno) << std::endl;
}
}
Abgespeichert als subproc.cpp und übersetzt mit "g++ -o subproc subproc.cpp" bekommst Du ein Binary mit dem Namen subproc. Das kannst Du dann beispielsweise so aufrufen:
./subproc ls foobar
Der führt ls aus und gibt seinen return code aus.
Christoph schrieb:
DrGreenthumb schrieb:
Den Softlink in /proc kann man aber sicher annehmen.
Kann man das? Ich kenn mich mit den Sicherheits-Erweiterungen, die es so für Linux gibt, nicht gut aus, aber bist du sicher, dass z.B. SELinux den Lesezugriff auf /proc/pid/exe nicht einfach einschränken kann?
oder /proc ganz wegnehmen. Dann gehts auch nicht...
Man muss ja immer abwägen wovon man abhängig sein möchte. Eine andere Möglichkeit, die dann vermutlich auch unter BSD oder so funktioniert, ist zu der exe ein Shellscript zu legen was z.B. eine Umgebungsvariable setzt und das stattdessen aufzurufen:
#/bin/bash
export MY_PROGRAM_DIRECTORY="$(dirname "$0")"
exec $MY_PROGRAM_DIRECTORY/prog "@"
meine so machen es auch openoffice & co.
Das funktioniert natürlich auch nicht wenn der Benutzer anfängt das Program in einen Scriptinterpreter zu pipen oder das Verzeichnis löscht, wo das Programm seine Daten lesen will
Hallo,
ich sollte dann eigentlich 3 Sockets haben
Der 1. ist der listener für einkommende Befehle von einem php-Script
Der 2. wird bei einer neuen Anfrage durch accept erzeugt und dort sollen die Anfragen angenommen und beantwortet werden. Die Überwachung funktioniert mit einem select
Der 3. geht an einen AVRnet-IO (auch biderektional)
Allerdings bekommt der 3. durch Socket die Socketnummer vom 2. zugewiesen, so dass das PHP Script immer die Anfrage bekommt die eigentlich an den AVRnet-IO gehen sollte...
Viele Grüße
Holger
nene wird alles innerhalb einer Desktop Session aufgerufen, habe jetzt auch meine default mimes gesetzt und alles funktioniert wie es soll.
Die Envs sind auch sauber, da gibt es kein Anzeichen darauf, woher noch was genommen haben könnte.
Naja hat sich ja jetzt alles geklärt, kann daher geschlossen werden.
Ich kenne sogar Linux/Unix Experten mit 20 jähriger Berufserfahrung, die Mac benutzen. Linux ist ein Bastlersystem. Irgedwann haben sogar einige Linuxfreaks keine Lust mehr zu basteln und wollen in Ruhe arbeiten. Mac funktioniert einfach. Es gibt viel weniger Probleme mit nicht funktionierenden Treibern, Hibernate, zickender Hardware usw. Mir persönlich sagt es aber auch nicht zu.
SeppJ schrieb:
SG1 schrieb:
Deine main.c liegt ja auch in src/ nicht in res/
Für den Pfad ist weder interessant, wo der Sourcecode liegt, noch wo die Executable liegt, sondern nur, was das aktuelle Arbeitsverzeichnis ist.
Richtig. In der letzten Frage ging's aber ums kompilieren.
