3. fehler bei getcwd

fehler bei getcwd

  • ?

    hi,

    versuche mein aktuelles Arbeitsverzeichnis zu finden. Hab ein bisschen in google gesucht und folgendes gefunden

    http://www.win-tux.de/c_019_002.htm#RxxobKap01900204002AF31F02C1A7

    meine Implementation:

    #include <unistd.h>
#include<stdio.h>
#include<stdlib.h>
int main(int argc, char* argv[]){
    char infile[_POSIX_PATH_MAX];
    string projectPath="";
    if (getcwd(infile, sizeof(infile))==NULL){
        cout<<"klappt"<<endl;
    }else{
        cout<<"noe"<<endl;
    }
}

    bekomme dabei fehler mit denen ich nicht wirklich was anfangen kann:

    mb: In function `__data_start':
(.data+0x8): multiple definition of `__dso_handle'
/usr/lib64/gcc/x86_64-suse-linux/4.1.0/crtbegin.o:(.data+0x0): first defined here
mb: In function `_init':
/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crti.S:25: multiple definition of `_init'
/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../lib64/crti.o:/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crti.S:11: first defined here
mb: In function `_start':
(.text+0x0): multiple definition of `_start'
/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../lib64/crt1.o:init.c:(.text+0x0): first defined here
mb: In function `_fini':
/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crti.S:37: multiple definition of `_fini'
/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../lib64/crti.o:/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crti.S:11: first defined here
mb:(.rodata+0x0): multiple definition of `_IO_stdin_used'
/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../lib64/crt1.o:(.rodata.cst4+0x0): first defined here
mb: In function `__data_start':
(.data+0x0): multiple definition of `__data_start'
/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../lib64/crt1.o:init.c:(.data+0x0): first defined here
/tmp/ccmrtBz5.o: In function `printHelp()':
main.cpp:(.text+0xe6): multiple definition of `printHelp()'
mb:(.text+0x1fc): first defined here
/tmp/ccmrtBz5.o: In function `main':
main.cpp:(.text+0x164): multiple definition of `main'
mb:(.text+0x31c): first defined here
/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld: Warning: size of symbol `main' changed from 635 in mb to 270 in /tmp/ccmrtBz5.o
/tmp/ccmrtBz5.o: In function `printVersion()':
main.cpp:(.text+0x272): multiple definition of `printVersion()'
mb:(.text+0x2ec): first defined here
collect2: ld returned 1 exit status

    In Python würd ich das einfach über "os.path.abspath(...)" machen

    0
  • D

    Normalerweise musst du da ja noch eine Lib mitlinken.

    Obwohl ich dir eigentlich eher zu boost::filesystem raten.
    http://www.boost.org/doc/libs/1_37_0/libs/filesystem/doc/index.htm

    Ist sehr angenehm und einfach zu handhaben. Dazu kommt noch, dass du dir auch (fast) keine Gedanken um das OS machen musst.

    0
  • L

    Zeig mal die Kommandozeile mit der Du linkst. Das sieht irgendwie so aus als würdest Du das ausführbare Programm mb mit dem Quelltext main.cpp zusammenlinken wollen.

    0
  • ?

    omg................

    vielen dank !!!!! man ich bin so doof, das ist wenn man so faul ist und den befehl nicht immer wieder neu eigeben will.

    hatte "g++ mb main.cpp" das -o sollt man noch mit angeben 🙄 "g++ -o mb main.cpp"

    ohne den tipp hätt ich wohl noch ewig gesucht^^ manchmal sinds so kleinigkeiten

    mit boost hab ich bisher noch gar nichts gemacht, werd ich mir aber auch mal anschauen.

    0
  • P

    davon abgesehen noch ein paar Einzelheiten betreffs Standrad-C++:
    - die Header <stdio.h> und <stdlib.h> sind veraltet, seit 1998 verlangt der C++ Standard, dass stattdessen die header <cstdio> und <cstdlib> benutzt werden (die enthalten die selben Funktionen, nur im namespace std)
    - die Funktionen in den Headern <stdio.h> und <stdlib.h> (bzw. in den entsprechenden Standard-C++ Headern) sind C-Funktionen, kein C++. Auch wenn die C-Bibliotheken aus Kompatibilitätsgründen in C++ aufgenommen wurden, gibts in C++ eigene Bibliotheken die die entsprechende Funktionalität bieten, die aus verschiedenen Gründen (objektorientierung, Typsicherheit,...) vorzuziehen sind.
    - die Funktionen der Header <stdio.h> und <stdlib.h> werden in deinem Codebesipiel nicht benutzt, daher solltest du sie auch nicht einbinden. Stattdessen benutzt du cout, ohne den entsprechenden HEader <iostream> einzubinden und ohne den namespace std zu benutzen. Der abgebildete Code KANN so also garnicht compilieren.

    0
  • ?

    jo sind draussen, hatte die nur zum testen drinne weil das in irgendnem beispiel von getcwd mit drinne waren und das die ganze zeit nicht geklappt hat.

    iostream und so sind in ner definition.h die ins gesamte projekt eingebuden wird (macht man das so ??)

    hatte auch nur den teil meiner main gepostet bei dem ich probleme hatte 🙂

    danke für den tipp mit den veralteten sachen, muss ich mal drauf achten wenn ich was im inet finde.

    0
  • P

    _-/ schrieb:

    iostream und so sind in ner definition.h die ins gesamte projekt eingebuden wird (macht man das so ??)

    Tendenziell eher nein. Es mag Ausnahmen geben, aber normalerweise bindet man in eine Datei genau die Header ein, von denen auch Elemente tatsächlich dort benutzt werden. Die "Große Headersammlung" für alles was im Projekt so vorkommen könnte, nimmt einem für den Moment zwar Tipparbeit ab (einfach jedesmal #include "mymonsterheadercollection.h"), aber vor allem wenns dann an Dinge geht, die nicht im Standard enthalten sind, erschwerts die Übersicht.

    #include "mymonsterheadercollection.h"
//...
do_foo(22, new Bla()); //do_foo bereitet Probleme - nur aus welchem der 50 Header in mymonsterheadercollection stammt es?

    Abgesehen davon speist man den Compiler damit in jeder Übersetzungseinheit mit Informationen die er garnicht braucht...

    Siehe dazu auch hier: http://www.gotw.ca/gotw/007.htm

    0
Anmelden zum Antworten