Ldflags “unresolved-symbols=ignore-all”



  • Hallo zusammen

    Compiler: GCC auf Raspbian 10.x

    Wie setzt mal ldflags „unresolved-symbols=ignore-all“ genau, weiss das jemand von euch?

    Linker error:

    /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/…/…/…/libxaxadevka.so: undefined reference to IowKitGetDeviceHandle' /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/../../../libxaxadevka.so: undefined reference to IowKitCloseDevice’
    /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/…/…/…/libxaxadevka.so: undefined reference to IowKitWrite' /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/../../../libxaxadevka.so: undefined reference to IowKitGetNumDevs’
    /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/…/…/…/libxaxadevka.so: undefined reference to IowKitRead' /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/../../../libxaxadevka.so: undefined reference to IowKitOpenDevice’
    /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/…/…/…/libxaxadevka.so: undefined reference to `IowKitGetProductId’

    Nun möchte ich das verhindern mit:

    eatmydata – cmake -DCMAKE_BUILD_TYPE=„Release“ > /dev/null 2>&1;
    eatmydata – make clean > /dev/null 2>&1;
    if [ „$(dpkg --print-architecture)“ == „amd64“ ]; then
    eatmydata – make -w -r -j4 CFLAGS=’-O0 -v’ LDFLAGS=’–unresolved-symbols=ignore-all’;
    else
    eatmydata – make -w -r -j4 CFLAGS=’-O0 -v’ LDFLAGS=’–unresolved-symbols=ignore-all’;
    fi;

    Klappt aber nicht.

    Ebenfalls nix, selbiger Fehler erscheint…

    eatmydata – cmake -DCMAKE_BUILD_TYPE=„Release“ > /dev/null 2>&1;
    eatmydata – make clean > /dev/null 2>&1;

    LDFLAGS="–unresolved-symbols=ignore-all";

    if [ „$(dpkg --print-architecture)“ == „amd64“ ]; then
    eatmydata – make -w -r -j4 CFLAGS=’-O0 -v’;
    else
    eatmydata – make -w -r -j4 CFLAGS=’-O0 -v’;
    fi;

    -> Wie löse ich das Problem?

    Danke für die Feedbacks…

    Grüsse,
    Jan



  • Ohne mich genauer mit deinem Problem befasst zu haben, so aus dem Bauch heraus ein paar Ideen:

    1. --unresolved-symbols=ignore-all meines wissens gehören da zwei Dashes hin bei dieser Option.
    2. nicht selten wird für das Linken der Compiler aufgerufen, der dann seinerseits den Linker aufruft, anstatt direkt der Linker. In diesem Fall muss eine für das Linker-Programm bestimmte Option in dieser Form übergeben werden: -Wl,--unresolved-symbols=ignore-all. Die LDFLAGS die mir in bisher meistens untergekommen sind, waren eigentlich alle solch linker-spezifischen Compiler-Flags.
    3. ich bin mir gar nicht sicher, ob die mit CMake erzeugten Makefiles überhaupt CFLAGS und LDFLAGS-Variablen verwenden wie autotools-generierte Makefile das meist tun. CMake selbst nimmt aber meines Wisses diese Umgebungsvariablen, um CMAKE_C_FLAGS, CMAKE_SHARED_LINKER_FLAGS und CMAKE_EXE_LINKER_FLAGS zu füllen. Versuche mal die Variablen vor dem CMake-Aufruf zu setzen, und zwar so, dass cmake sie auch sehen kann:
    export CFLAGS="-O0 -v"
    export LDFLAGS="-Wl,--unresolved-symbols=ignore-all"
    eatmydata -- cmake -DCMAKE_BUILD_TYPE="Release" > /dev/null 2>&1
    

    Keine Ahnung was eatmydata macht. Ich hoffe, das ist nicht auch noch eine mögliche Ursache für dein Problem.

    Alternativ kannst du auch die entprechenden CMake-Variablen direkt setzen:

    eatmydata -- cmake \
        -DCMAKE_BUILD_TYPE="Release" \
        -DCMAKE_C_FLAGS="-O0 -v" \
        -DCMAKE_SHARED_LINKER_FLAGS="-Wl,--unresolved-symbols=ignore-all" \
        > /dev/null 2>&1
    

    und zu guter letzt: CFLAGS sind nur für C-Compiler! Wenn es sich um C++ handeln sollte (du hast im C++-Forum gepostet) muss es natürlich CXXFLAGS und CMAKE_CXX_FLAGS heissen!

    P.S.: – vs - ... hast du das mit einem Editor geschrieben, der dir ein Doppel-Minus ungefragt in einen langen Bindestrich umwandelt? Das muss meines erachtens eigentlich überall -- heissen. Bitte genau darauf achten, Programmcode ist da sehr sensibel und es wird für andere Leute schwer, dein Problem festzunageln wenn der gepostete Code nicht exakt derjenige ist, der den Fehler erzeugt.



  • Besten Dank für deine schnelle Antwort, werde es mir ASAP anschauen! 🙂

    "und zu guter letzt: CFLAGS sind nur für C-Compiler! Wenn es sich um C++ handeln sollte (du hast im C++-Forum gepostet) muss es natürlich CXXFLAGS und CMAKE_CXX_FLAGS heissen!"

    Danke, wusste ich bis anhin nicht. (Bin auch eher für die Build/Deployment-Prozesse verantwortlich als für die eigentliche Programmierung... und die Programmierer wissen teilweise auch nicht jedes Detail betr. Kompiler-Anweisungen/Parameters welche es bei C/C++ MASSENHAFT gibt...

    -> Wie ist das mit den Linker-Flags bei C/C++ gibt es dort auch Unterschiede C vs. C++ ? Oder heisst das immer gleich?



  • @jmar83 sagte in Ldflags “unresolved-symbols=ignore-all”:

    -> Wie ist das mit den Linker-Flags bei C/C++ gibt es dort auch Unterschiede C vs. C++ ? Oder heisst das immer gleich?

    Nein, im allgemeinen gibt es da keine Unterschiede. Es gibt keine etablierte LDFLAGS-Umgebungsvariable nur für C++ und auch CMake macht da keinen Unterschied.



  • Vielen vielen Dank!! 🙂



  • @Finnegan sagte in Ldflags “unresolved-symbols=ignore-all”:

    Keine Ahnung was eatmydata macht.

    Das beschleunigt ein wenig, indem es einen Teil des Schreibcache aushebelt. Läuft ganz flott damit, vor allem in Kombination mit "ccache"... :- )

    Bin gerade dran, deine vorgeschlagene Lösung auszuprobieren... 🙂 Nochmal vielen Dank!!



  • @Finnegan sagte in Ldflags “unresolved-symbols=ignore-all”:

    P.S.: – vs - ... hast du das mit einem Editor geschrieben, der dir ein Doppel-Minus ungefragt in einen langen Bindestrich umwandelt? Das muss meines erachtens eigentlich überall -- heissen. Bitte genau darauf achten, Programmcode ist da sehr sensibel und es wird für andere Leute schwer, dein Problem festzunageln wenn der gepostete Code nicht exakt derjenige ist, der den Fehler erzeugt.

    Ist ein copy/paste vom Bitvise SSH Client (cat my_script.sh) wenn ich mich richtig erinnere.



  • Damit hat's nun geklappt, aber erst als ich die "export ... "-Anweisungen gesetzt habe...

    BESTEN DANK!!! 🙂

    Hier nochmal copy/paste aus der Bitvise SSH-Client Konsole / cat MY_SCRIPT.sh...

    rm -f CMakeCache.txt;
    rm -rf CMakeFiles;
    
    export CFLAGS="-O0 -v";
    export CXXFLAGS="-O0 -v";
    export LDFLAGS="-Wl,--unresolved-symbols=ignore-all";
    
    eatmydata -- cmake -DCMAKE_BUILD_TYPE="Release" -DCMAKE_CXX_FLAGS="-O0 -v" -DCMAKE_C_FLAGS="-O0 -v" -DCMAKE_SHARED_LINKER_FLAGS="-Wl,--unresolved-symbols=ignore-all" > /dev/null 2>&1;
    eatmydata -- make clean > /dev/null 2>&1;
    
    if [ "$(dpkg --print-architecture)" == "amd64"  ]; then
      eatmydata -- make -w -r -j4 CFLAGS='-O0 -v' CXXFLAGS='-O0 -v';
    else
      eatmydata -- make -w -r -j4 CFLAGS='-O0 -v' CXXFLAGS='-O0 -v';
    fi;
    

    -> Dieses mal aber in einen Code-Block mit der "Keine" [in der Auswahlliste definierte Sprache]

    ...evtl. ist nun aber etwas zuviel, doppelt gemoppelt quasi. 😉

    Vielleicht fällt dir gerade was auf, das man entfernen könnte...?



  • @jmar83 sagte in Ldflags “unresolved-symbols=ignore-all”:

    ...evtl. ist nun aber etwas zuviel, doppelt gemoppelt quasi. 😉

    Vielleicht fällt dir gerade was auf, das man entfernen könnte...?

    Dafür stecke ich zu wenig in diesen speziellen Build-Skripten drin. Aber so ist das natürlich 3fach redundant: export CFLAGS=... wird von CMake nach CMAKE_C_FLAGS übernommen, die du aber auch nochmal explizit setzt. Ebenso überschreibst du mit den make-Parametern auch nochmal die von CMake gesetzten Flags (falls das Makefile überhaupt diese Variablen akzeptiert und nicht einfach stillschweigend ignoriert).

    Da es sich scheinbar um ein CMake-Projekt handelt, würde ich mal versuchen, das ausschlieslich via Argumenten für CMake zu setzen, also die -DCMAKE_C_FLAGS=... etc. und schauen ob es dann immer noch klappt. Der Rest kann dann weg.

    Auch der Test auf "amd64" macht m.E. wenig Sinn, da die von CMake generierten Makefiles einen absoluten Pfad zum (in diesem Fall) Default-Compiler der Build-Maschine beinhalten werden. CMake sucht da den passenden Compiler.

    Wenn du da eine Weiche für architektur-spezifische Compiler benötigst, dann solltest du den CMake-Aufruf in den if/else-Block packen und den gewünschten Compiler und Flags entsprechend setzen, z.B. vielleicht so: cmake ... -DCMAKE_C_COMPILER=x86_64-linux-gnu-gcc -DCMAKE_CXX_COMPILER=x86_64-linux-gnu-g++, wenn amd64 oder cmake ... -DCMAKE_C_COMPILER=arm-linux-gnueabihf-gcc -DCMAKE_CXX_COMPILER=arm-linux-gnueabihf-g++ wenn ARM. Ist aber alles von deinem System abhängig und wie die Compiler heissen.



  • @Finnegan sagte in Ldflags “unresolved-symbols=ignore-all”:

    -DCMAKE_C_FLAGS

    -DCMAKE_C_FLAGS sowie -DCMAKE_CXX_FLAGS habe ich zuerst bei "cmake" gesetzt, ging leider nicht. Dann noch als zweiter Schritt bei "make" - damit war das Problem ebenfalls noch nicht gelöst. (Aber der Compikler-Output hat sich dann irgendwie verändert)

    Erst mit "export ... " ging's dann.

    Beim if/else stand vorher was anderes drin, klar, macht so nicht wirklich Sinn... 🙂



  • @jmar83 Ich hab das natürlich aus dem Kopf geschrieben und nicht selbst gestestet. Das hört sich so an als ob die CMake-Variablen dafür eventuell anders heissen. Ich dachte die nicht build-type-spezifischen CMake-Variablen wären CMAKE_C_FLAGS und so.

    Probier es mal mit CMAKE_C_FLAGS_RELEASE, CMAKE_CXX_FLAGS_RELEASE und CMAKE_SHARED_LINKER_FLAGS_RELEASE ... bei CMAKE_BUILD_TYPE="Debug" müssen die dann natürlich ein _DEBUG-Suffix statt _RELEASE haben. Oder einfach bei dem export bleiben. Auf jeden Fall würde ich nicht 3x dasselbe machen, das wird später nur immer umständlicher zu warten.



  • Vielen Dank, werde das ASAP anschauen!! 🙂



  • Got it!! 🙂

    rm -f CMakeCache.txt;
    rm -rf CMakeFiles;

    export CFLAGS="-O0 -v";
    export CXXFLAGS="-O0 -v";
    export LDFLAGS="-Wl,--unresolved-symbols=ignore-all";

    eatmydata -- cmake -DCMAKE_BUILD_TYPE="Release" > /dev/null 2>&1;
    eatmydata -- make clean > /dev/null 2>&1;
    eatmydata -- make -w -r -j4;


Anmelden zum Antworten