Buggfix Plus
Aktuellt datum och tid: 11.40 2019-03-26

Alla tidsangivelser är UTC + 1 timme




Svara på tråd  [ 29 inlägg ]  Gå till sida Föregående  1, 2
Författare Meddelande
InläggPostat: 10.27 2018-12-09 
Användarvisningsbild

Blev medlem: 16.34 2004-09-06
Inlägg: 23061
Ort: Sparreholm, Södermanland N 59° 4.134', E 16° 49.743'
Kanske denna sidan kan reda ut lite command line grejer för dig

https://www.raspberrypi.org/documentati ... ommands.md


Upp
 Profil  
 
InläggPostat: 10.36 2018-12-09 
Användarvisningsbild

Blev medlem: 18.06 2010-05-17
Inlägg: 8801
Ort: Växjö/Alvesta
Magnus_K skrev:
Det jag fortfarande är genuint kass på är att få till alla argument rätt i terminalen när man tex ska kompilera, köra, kopiera, radera etc etc, men det kommer väl med tiden.



Så är det, det blir bättre med tiden.

Sen handlar mycket också om att lära sig att läsa och tolka funktionernas hjälptexter (typiskt kommando -h eller kommando --help), och manualen (man kommando, om man sitter på ett system med manualen installerad, annars samma sak skrivet i google). :)


Upp
 Profil  
 
InläggPostat: 12.28 2018-12-09 

Blev medlem: 10.06 2010-01-07
Inlägg: 820
Ort: Sandared
Det tar sin tid, men du kan få rätt mycket hjälp här på forumet :)

Jag själv har jobbat med linux sista 20 år, så en del av saker man tar för givet eftersom de sitter i ryggmärgen, men skriv gärna när du behöver något hjälp.

Bli försiktigt med sudo, den kan bli både hjälpsam och skadligt, så använd den bara när du måste.

För att få alla argument till kommando du ska använda, använd kommando_namn --help, du borde få allt där, sen om det räcker inte, då är det man kommando_namn som du ska kolla nästa, där du har manual för den kommando du vill ha och sen om det hjälper inte heller, hojta till här så vi hjälper dig ;)


Upp
 Profil  
 
InläggPostat: 13.06 2018-12-09 

Blev medlem: 06.51 2008-05-19
Inlägg: 21417
Ort: Upplands väsby
När det gäller cd .. är det mycket riktigt mellanslaget som linux kräver men Windows struntar i.

Jag tycker att det är bra att förklara varför när man säger åt nån att "då ska du köra xxx istället". Jag hatar när det är guider som bara rabblar upp en massa kommandon utan att förklara nyttan med dem.

Sidan som tecno länkar till ser ut att vara rätt bra.


Upp
 Profil  
 
InläggPostat: 23.16 2018-12-09 
EF Sponsor
Användarvisningsbild

Blev medlem: 17.53 2010-01-04
Inlägg: 5205
Ort: Skogen mellan Uppsala-Gävle
Super med all support!
Jag ska inte tjata ihjäl er med dumheter, men som exempel så händer följande rätt ofta, och jag blir då helt handlingsförlamad:

"Någon guide" på nätet skriver att man ska köra följande kommando för att få önskat resultat:
sudo g++ -lwiringPi TX_Demo.cpp cc1100_raspi.cpp -o TX_Demo

Visst fungerar det kanon, men jag vill veta mer.
Det jag vet är följande:
    * Mest troligt måste köra det som superuser,
    * använda mig av kompilatorn g++,
    * filen som ska kompileras är TX_Demo.cpp,
    * och den körbara filen ska heta TX_Demo.

Pusselbitarna som saknas är således lwiringPi och cc1100_raspi.cpp.
Det finns ingen man-fil för g++ men en hjälp, den ser ut som nedan.
Om jag minns rätt så läste jag någonstans att man ska sätta ett "l" före wiringPi om man använder det, men hur kommer det in i bilden över huvudtaget? Vad gör också filen cc1100_raspi.cpp i det här kommandot? (det är en fil i mappen som mycket riktigt heter så men försöker förstå lite mer)
Kod: [Expandera/Minimera] [Hämta] (Untitled.txt)
  1. Usage: g++ [options] file...
  2. Options:
  3.   -pass-exit-codes         Exit with highest error code from a phase.
  4.   --help                   Display this information.
  5.   --target-help            Display target specific command line options.
  6.   --help={common|optimizers|params|target|warnings|[^]{joined|separate|undocumented}}[,...].
  7.                            Display specific types of command line options.
  8.   (Use '-v --help' to display command line options of sub-processes).
  9.   --version                Display compiler version information.
  10.   -dumpspecs               Display all of the built in spec strings.
  11.   -dumpversion             Display the version of the compiler.
  12.   -dumpmachine             Display the compiler's target processor.
  13.  -print-search-dirs       Display the directories in the compiler's search path.
  14.   -print-libgcc-file-name  Display the name of the compiler's companion library.
  15.  -print-file-name=<lib>   Display the full path to library <lib>.
  16.  -print-prog-name=<prog>  Display the full path to compiler component <prog>.
  17.  -print-multiarch         Display the target's normalized GNU triplet, used as
  18.                            a component in the library path.
  19.   -print-multi-directory   Display the root directory for versions of libgcc.
  20.   -print-multi-lib         Display the mapping between command line options and
  21.                            multiple library search directories.
  22.   -print-multi-os-directory Display the relative path to OS libraries.
  23.   -print-sysroot           Display the target libraries directory.
  24.   -print-sysroot-headers-suffix Display the sysroot suffix used to find headers.
  25.   -Wa,<options>            Pass comma-separated <options> on to the assembler.
  26.   -Wp,<options>            Pass comma-separated <options> on to the preprocessor.
  27.   -Wl,<options>            Pass comma-separated <options> on to the linker.
  28.   -Xassembler <arg>        Pass <arg> on to the assembler.
  29.   -Xpreprocessor <arg>     Pass <arg> on to the preprocessor.
  30.   -Xlinker <arg>           Pass <arg> on to the linker.
  31.   -save-temps              Do not delete intermediate files.
  32.   -save-temps=<arg>        Do not delete intermediate files.
  33.   -no-canonical-prefixes   Do not canonicalize paths when building relative
  34.                            prefixes to other gcc components.
  35.   -pipe                    Use pipes rather than intermediate files.
  36.   -time                    Time the execution of each subprocess.
  37.   -specs=<file>            Override built-in specs with the contents of <file>.
  38.   -std=<standard>          Assume that the input sources are for <standard>.
  39.   --sysroot=<directory>    Use <directory> as the root directory for headers
  40.                            and libraries.
  41.   -B <directory>           Add <directory> to the compiler's search paths.
  42.  -v                       Display the programs invoked by the compiler.
  43.  -###                     Like -v but options quoted and commands not executed.
  44.  -E                       Preprocess only; do not compile, assemble or link.
  45.  -S                       Compile only; do not assemble or link.
  46.  -c                       Compile and assemble, but do not link.
  47.  -o <file>                Place the output into <file>.
  48.  -pie                     Create a position independent executable.
  49.  -shared                  Create a shared library.
  50.  -x <language>            Specify the language of the following input files.
  51.                           Permissible languages include: c c++ assembler none
  52.                           'none' means revert to the default behavior of
  53.                           guessing the language based on the file's extension.
  54.  
  55. Options starting with -g, -f, -m, -O, -W, or --param are automatically
  56.  passed on to the various sub-processes invoked by g++.  In order to pass
  57.  other options on to these processes the -W<letter> options must be used.
  58.  
  59. For bug reporting instructions, please see:
  60. <file:///usr/share/doc/gcc-6/README.Bugs>.


Upp
 Profil  
 
InläggPostat: 23.21 2018-12-09 

Blev medlem: 10.06 2010-01-07
Inlägg: 820
Ort: Sandared
Du behöver inte köra som sudo så länge du inte installerar kompilerade programm till någon systemmapp som /usr/bin, /sbin, osv.

Rästen du har fattat bra, -o är namn på output programm, cc1100_raspi.cpp är källkod fil, c++ fil.

lwiringpi betyder använd library wiringpi som är GPIO Interface library for the Raspberry Pi


Upp
 Profil  
 
InläggPostat: 23.36 2018-12-09 
EF Sponsor
Användarvisningsbild

Blev medlem: 17.53 2010-01-04
Inlägg: 5205
Ort: Skogen mellan Uppsala-Gävle
Ahaa ok. Nu har jag i och för sig inte testat utan sudo än, men ska försöka att alltid börja utan för att inte ställa till med något.
Men om cc1100_raspi.cpp är källkods-filen som ska kompileras, hur kommer då TX_Demo.cpp in i bilden? det känns som att det är en C++ fil för mycket med i kommandot?

l = library :tumupp:


Upp
 Profil  
 
InläggPostat: 23.51 2018-12-09 

Blev medlem: 14.43 2007-06-14
Inlägg: 4021
Ort: Hälsingland
Nej bägge ska nog med, cc1100_raspi.cpp är sannolikt kod för radion och TX_Demo.cpp kod för "programmet" som använder sig av den första.


Upp
 Profil  
 
InläggPostat: 23.52 2018-12-09 
EF Sponsor
Användarvisningsbild

Blev medlem: 15.29 2005-05-10
Inlägg: 37310
Ort: Söderköping
Finns så klart massor av beskrivning ar av GCC/G++ process för kompilering/länkning,
men denna var en tidig träff och verkar ganska vettig:
https://www3.ntu.edu.sg/home/ehchua/programming/cpp/gcc_make.html

Där finns även en enkel (kanske förenklad, men i alla fall) bild av processen:
Bild

> det känns som att det är en C++ fil för mycket med i kommandot?

Du kan ha hur många källkodsfiler som du vill/behöver i kommandot.
Men normalt så hade jag kanske förväntat att cc1100_raspi hade varit
förkompilerad som en "library" (och alltså inkluderar med -l), men det
kanske finns någon anledning till att den kompileras varje gång.

TX_Demo.cpp bör vara det som är din "applikation". Inte cc1100_raspi,
det är bara olika funktioner till CC1100 modulen. Se även:
https://github.com/SpaceTeddy/CC1101/blob/master/cc1100_raspi.cpp
"CC1100 Raspberry Pi Library". Det är alltså ett "bibliotek" med rutiner för
CC1100, även om det rent tekniskt inte hanteras som ett "library"... :-)


Upp
 Profil  
 
InläggPostat: 00.24 2018-12-10 
Användarvisningsbild

Blev medlem: 11.56 2004-05-08
Inlägg: 3108
Ort: Stockholm
Magnus_K skrev:
Ahaa ok. Nu har jag i och för sig inte testat utan sudo än, men ska försöka att alltid börja utan för att inte ställa till med något.

När du kör kommandot som root (med sudo) så skapas filen TX_Demo med ägare root - skriv 'ls -l' så ser du att filen ägs av root. Om du sedan försöker köra kommandot som din vanliga användare (utan sudo) så kommer det inte att ha rättighet att skriva över (ersätta) den tidigare skapta root-ägda filen och du får ett felmeddelande. Så ta bort den TX_Demo som du skapade som root innan du kör kommandot utan sudo.

Använd 'sudo rm TX_Demo' för detta.


Upp
 Profil  
 
InläggPostat: 19.09 2018-12-10 

Blev medlem: 06.51 2008-05-19
Inlägg: 21417
Ort: Upplands väsby
Jag skulle personligen inte kompilera som root bara för att det exekverbara programmet ska ägas av root.

Det är i såna fall bättre att köra "sudo chown root TX_Demo" efter kompileringen tycker jag.

Fördelen är att om kompileringen av nån anledning löper amok så vill man inte att kompilatorn körs som root med risken att den skriver över viktiga systemfiler (ok, just kompilering är kanske inte jättefarligt, men det är en bra vana att inte köra nåt som root förrän man behöver).


Det är lite lurigt att förstå hur en kompilator fungerar, är man van att kompilera en C-fil till en exekverbar fil så har man inte sett hela bilden.

Men som sodjans bild visar:

Först kompileras varje cpp-fil för sig (den körs genom pre-processor först). Det ger en massa så kallade "objektfiler", som alltså i princip innehåller kompilerade funktioner.

Sen länkas alla objektfiler, eventuellt tillsammans med externa libraries (som också är objektfiler). Länkaren tar normalt bara med de funktioner som anropas av en annan funktion (plus funktionen main(), som ju är programmets start).

Länkaren lägger alltså ett pussel kan man säga, det är det pusslet som blir ditt körbara program.


Upp
 Profil  
 
InläggPostat: 20.33 2018-12-10 
EF Sponsor
Användarvisningsbild

Blev medlem: 17.53 2010-01-04
Inlägg: 5205
Ort: Skogen mellan Uppsala-Gävle
Nu när ni säger det så kan det hända jag har gjort så här i något annat projekt också.
Dock väldigt "ovant" för mig att hantera mer än en källfil, projekten brukar liksom inte bli så omfattande :wink:

Misstänker man kan ganska snarlikt jämföra det med när man inkluderar en biblioteksfil i Arduino eller i annan platform. Varje gång jag då kompilerar källfilen så hänger dom länkade filerna med?
Det kanske är det här som är skillnaden om man gör en Build mot Build all, som finns i vissa miljöer?

Ska testa att göra lite ägarbyte och annat senare. Tror jag förstår allt ni skriver, för en gång skull.


Upp
 Profil  
 
InläggPostat: 20.56 2018-12-10 

Blev medlem: 06.51 2008-05-19
Inlägg: 21417
Ort: Upplands väsby
Vid större projekt så använder man ju oftast make.

Då kompileras alla .c och .cpp etc först var och en för sig (man har ett "recept" som säger att typ att ".c ska kompileras med gcc till en .obj och .cpp ska kompilera med g++ till en -obj"). Make är "smart" på så vis att den kollar tidsstämpeln på varje källkodsfil och objektfil. Om källkodsfilen är nyare än objektfilen så kompileras källkodsfilen om, men om objektfilen är nyare så struntar den normalt i att kompilera.

Sen när alla källkodsfiler är kompilerade så körs länk-kommandot.


I en make-fil kan man ha olika "targets", t.ex. "make clean" som alltså inte kompilerar nåt utan istället rensar alla "arbetsfoldrar" så man börjar om från början.


Googlade fram en enkelt tutorial om make, notera att de första exempel är spartanska, det är när du kommer ner till Makefile 3 och 4 börjar det se ut som det "brukar".
http://www.cs.colby.edu/maxwell/courses ... maketutor/

Här finns ett exempel på en make-fil som är mer "manuellt" skriven
https://www.gnu.org/software/make/manua ... efile.html


Upp
 Profil  
 
InläggPostat: 00.24 2018-12-11 
EF Sponsor
Användarvisningsbild

Blev medlem: 15.29 2005-05-10
Inlägg: 37310
Ort: Söderköping
> Varje gång jag då kompilerar källfilen så hänger dom länkade filerna med?

Lite oklart vad "de länkade filerna" betyder, men om du menar "libraries"
så är det korrekta svaret "nej". Inga libraries används vid kompileringen,
de används vid länkningen.

Sen är det en annan sak att gcc/g++ automatiskt anropar länkaren åt dig,
men det är fortfarande rent tekniskt ett separat länknings steg.

Det som brukar kallas "Build" och "Build All" i en del miljöer är ofta en slags
inbyggd make funktion. "Build" kompilerar om det som behöver kompileras om.
"Build All" kompilerar om allt oavsett om det behövs eller inte.


Upp
 Profil  
 
Visa inlägg nyare än:  Sortera efter  
Svara på tråd  [ 29 inlägg ]  Gå till sida Föregående  1, 2

Alla tidsangivelser är UTC + 1 timme


Vilka är online

Användare som besöker denna kategori: ooptimerad och 3 gäster


Du kan inte skapa nya trådar i denna kategori
Du kan inte svara på trådar i denna kategori
Du kan inte redigera dina inlägg i denna kategori
Du kan inte ta bort dina inlägg i denna kategori
Du kan inte bifoga filer i denna kategori

Sök efter:
Hoppa till:  
    Electrokit
Drivs av phpBB® Forum Software © phpBB Group
Swedish translation by Peetra & phpBB Sweden © 2006-2010