Vinnaren i pepparkakshustävlingen!
2024-08-26, 19:01
  #3241
Medlem
Citat:
Ursprungligen postat av Methos
Hmm ja, static enum Benchmark..... verkar fungerar.

I övrigt gör jag inget speciellt med min kod, då jag försöker kompilera:
https://github.com/osmocom/rtl-sdr/b...src/rtl_test.c
Jag får en väldigt massa konstiga redefs däri, när Linux inte använder test.h utan linux/test.h,
Jag försöker återuppliva RTL_SDR-lib från C till CPP för att kunna skapa ett bättre program i CPP.

Dock lutar det mer åt att det är Visual Code som spökar, då jag helt plötsligt inte får några redefs. Utan jag har nu tappat alla definitioner till olika funktioner i rtl-sdr.h, som inte ger mig felmeddelande i Code, men som ger mig undef i g++-11. Det hjälper inte att det var nästan 30 år sedan jag ens tittade på C kod.

Kan det vara så att du försöker kompilera rtl_test.c och länka den enskilt? Du kan kompilera filen enskilt utan att länka den (utan att blanda in linkern och få en objektfil istället genom att ange -c till compilern). Byggprocessen av programmet 'rtl_test' är förmodligen beroende av andra filer också för länkningen. Visual Code ser att allting finns definierat i källkoden, men linkern hittar inte allt i processen om du bara kör rtl_test.c. Utan då får du upp en massa 'undefined reference to ...'. Kolla Makefile:n vilka (objekt/source-)filer rtl-test är beroende av. Objektkod till dessa måste delges till linkern, eller kompileras samtidigt.
Citera
2024-08-26, 19:09
  #3242
Medlem
Citat:
Ursprungligen postat av FaderBerg
Kan det vara så att du försöker kompilera rtl_test.c och länka den enskilt? Du kan kompilera filen enskilt utan att länka den (utan att blanda in linkern och få en objektfil istället genom att ange -c till compilern). Byggprocessen av programmet 'rtl_test' är förmodligen beroende av andra filer också för länkningen. Visual Code ser att allting finns definierat i källkoden, men linkern hittar inte allt i processen om du bara kör rtl_test.c. Utan då får du upp en massa 'undefined reference to ...'. Kolla Makefile:n vilka (objekt/source-)filer rtl-test är beroende av. Objektkod till dessa måste delges till linkern, eller kompileras samtidigt.


Oh..
Är det så det förhåller sig. Jag antog att rtl_fm.c, rtl_sdr.c, rtl_test.c var självstående då de hade varsin main() och du kan även starta varje modul självständigt när du kör rtl-sdr "live". Jag har inte kollat cmake-filen då jag inte rör cmake just nu.

Jag antog att main() funktionen i dessa moduler var ekvivalent med "if __name__=="__main__" som används i python för att just skilja på runtime som modul och runtime som självständigt program.
Citera
2024-08-26, 20:13
  #3243
Medlem
Citat:
Ursprungligen postat av Methos
Oh..
Är det så det förhåller sig. Jag antog att rtl_fm.c, rtl_sdr.c, rtl_test.c var självstående då de hade varsin main() och du kan även starta varje modul självständigt när du kör rtl-sdr "live". Jag har inte kollat cmake-filen då jag inte rör cmake just nu.

Jag antog att main() funktionen i dessa moduler var ekvivalent med "if __name__=="__main__" som används i python för att just skilja på runtime som modul och runtime som självständigt program.

Ja det är det kan man väl säga. i Python har du imports av moduler med funktioner du vill använda. Pythontolken läser in dessa vid start och "länkar" on-the-fly så att säga.
Funktionen rtlsdr_open används t.ex. säkert av alla ovanstående program. Koden till den funktionen ligger i filen librtlsdr.c (fast funktionen är deklarerad i rtlsdr.h). När du bara kör rtl_test.c genom kompilern utan -c, så skickar den sin produkt vidare till linkern för att länka ihop all maskinkod och skapa en exekverbar fil. Linkern vet då inte var den ska hitta koden för rtlsdr_open.

EDIT:
Har du librtlsdr (shared library) installerat på ditt system så kan du säga åt linkern att hitta dess funktioner där, genom att ange '-l rtlsdr' till kompilern.
__________________
Senast redigerad av FaderBerg 2024-08-26 kl. 20:35.
Citera
2024-08-26, 20:36
  #3244
Medlem
Citat:
Ursprungligen postat av FaderBerg
Ja det är det kan man väl säga. i Python har du imports av moduler med funktioner du vill använda. Pythontolken läser in dessa vid start och "länkar" on-the-fly så att säga.
Funktionen rtlsdr_open används t.ex. säkert av alla ovanstående program. Koden till den funktionen ligger i filen librtlsdr.c (fast funktionen är deklarerad i rtlsdr.h). När du bara kör rtl_test.c genom kompilern utan -c, så skickar den sin produkt vidare till linkern för att länka ihop all maskinkod och skapa en exekverbar fil. Linkern vet då inte var den ska hitta koden för rtlsdr_open.

Tack, det fungerade. Nu skall jag se om jag kan klara av att återskapa rtil-sdr med multimon-ng i samma program.
(ja, jag inser att lek med IOstream och signalteknisk kod kanske inte är rätt sida ifall man vill fräscha upp sin kodkunskap. Dock är det ett intressant område att koda.)

Citat:
Ursprungligen postat av FaderBerg
EDIT:
Har du librtlsdr (shared library) installerat på ditt system så kan du säga åt linkern att hitta dess funktioner där, genom att ange '-l rtlsdr' till kompilern.

Jag vill helst inte leka med systemets libs. såsom librtlsdr och det släktet är skrivet är dessa libs mer känsliga än python när det gäller att bli kontaminerade. Därför använder jag inte systemets librtlsdr, då den är sammanbunden med Soapy och en rad andra libs.

Jag backade när jag märkte att Visual Code ville röra i /include/time.h och linux/time.h. Tur nog kan inte Visual Code röra dessa filer, då linux inte är Windows. time.h är en rätt systemskyddad fil i systemet så den kräver sudo.
__________________
Senast redigerad av Methos 2024-08-26 kl. 20:54.
Citera

Skapa ett konto eller logga in för att kommentera

Du måste vara medlem för att kunna kommentera

Skapa ett konto

Det är enkelt att registrera ett nytt konto

Bli medlem

Logga in

Har du redan ett konto? Logga in här

Logga in