Fehlermeldung Atmel Studio cannot find -l

[Thomas K. (thomaskroger)]

Moinsen,

folgendes Problem in Atmel Studio 7.0:

Beim Linken findet avr-gcc.exe die Libraries nicht (cannot find 
-lcmd.h), obwohl diese im Verzeichnis sind 
(H:\foo\TSW\AtmelStudio\cmd.h) und das Verzeichnis in den Optionen 
angegeben ist (-Wl,-L"H:\foo\TSW\AtmelStudio")
Der Compiler findet alle.

Es funktionierte jahrelang mit Make auf WinAVR. Nach Update auf Windows 
10 funzte das Make mit WinAVR nicht mehr. sh.exe hatte ein Problem mit 
cygwin.

Bei der Umstellung auf die AS-Toolchain nun o.g. Problem.

Hat jemand eine Idee dazu?

mny tnx


------ Build started: Project: YanuxNet, Configuration: Release AVR 
------
Build started.
Project "YanuxNet.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; 
('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "C:\Program Files 
(x86)\Atmel\7.0\Vs\Compiler.targets" from project 
"H:\foo\TSW\AtmelStudio\YanuxNet.cproj" (target "Build" depends on it):
  Using "RunCompilerTask" task from assembly "C:\Program Files 
(x86)\Atmel\7.0\Extensions\Application\AvrGCC.dll".
  Task "RunCompilerTask"
    Shell Utils Path C:\Program Files (x86)\Atmel\7.0\shellUtils
    C:\Program Files (x86)\Atmel\7.0\shellUtils\make.exe all
    Building file: .././cmd.c
    Invoking: AVR/GNU C Compiler : 4.9.2
    "C:\Program Files 
(x86)\Atmel\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c 
-funsigned-char -funsigned-bitfields -DNDEBUG  -I"C:\Program Files 
(x86)\Atmel\7.0\Packs\atmel\ATmega_DFP\1.0.90\include" 
-I"H:\foo\TSW\AtmelStudio"  -Os -ffunction-sections -fdata-sections 
-fpack-struct -fshort-enums -mrelax -Wall -mmcu=atmega1284p -B 
"C:\Program Files 
(x86)\Atmel\7.0\Packs\atmel\ATmega_DFP\1.0.90\gcc\dev\atmega1284p" -c 
-std=gnu99 -MD -MP -MF "cmd.d" -MT"cmd.d" -MT"cmd.o"   -o "cmd.o" 
".././cmd.c"

    Finished building: .././cmd.c
    Building file: .././YanuxNet.c
    Invoking: AVR/GNU C Compiler : 4.9.2
    "C:\Program Files 
(x86)\Atmel\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c 
-funsigned-char -funsigned-bitfields -DNDEBUG  -I"C:\Program Files 
(x86)\Atmel\7.0\Packs\atmel\ATmega_DFP\1.0.90\include" 
-I"H:\foo\TSW\AtmelStudio"  -Os -ffunction-sections -fdata-sections 
-fpack-struct -fshort-enums -mrelax -Wall -mmcu=atmega1284p -B 
"C:\Program Files 
(x86)\Atmel\7.0\Packs\atmel\ATmega_DFP\1.0.90\gcc\dev\atmega1284p" -c 
-std=gnu99 -MD -MP -MF "YanuxNet.d" -MT"YanuxNet.d" -MT"YanuxNet.o"   -o 
"YanuxNet.o" ".././YanuxNet.c"
    Finished building: .././YanuxNet.c
    Building target: YanuxNet.elf
    Invoking: AVR/GNU Linker : 4.9.2
    "C:\Program Files 
(x86)\Atmel\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -o 
YanuxNet.elf  cmd.o YanuxNet.o   -Wl,-Map="YanuxNet.map" 
-Wl,--start-group -Wl,-lcmd.h -Wl,-ltms.h -Wl,-lm  -Wl,--end-group 
-Wl,-L"H:\foo\TSW\AtmelStudio"  -Wl,--gc-sections -mrelax 
-mmcu=atmega1284p -B "C:\Program Files 
(x86)\Atmel\7.0\Packs\atmel\ATmega_DFP\1.0.90\gcc\dev\atmega1284p"

cannot find -lcmd.hcannot find -ltms.hcollect2.exe(0,0): error: ld

returned 1 exit status
    make: *** [YanuxNet.elf] Error 1
    The command exited with code 2.
  Done executing task "RunCompilerTask" -- FAILED.
Done building target "CoreBuild" in project "YanuxNet.cproj" -- FAILED.
Done building project "YanuxNet.cproj" -- FAILED.

Build FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped 
==========



Toolchain: AVR/GNU Linker:
Command: avr-gcc

All Options:
-Wl,-Map="$(OutputFileName).map" -Wl,--start-group -Wl,-lcmd.h 
-Wl,-ltms.h -Wl,-lm  -Wl,--end-group -Wl,-L"H:\foo\TSW\AtmelStudio" 
-Wl,--gc-sections -mrelax -mmcu=atmega1284p -B "C:\Program Files 
(x86)\Atmel\7.0\Packs\atmel\ATmega_DFP\1.0.90\gcc\dev\atmega1284p"

[Peter II (Gast)]

Thomas K. schrieb:
> -lcmd.h

was soll das darstellen? eine Headerdatei ist doch keine lib die man den 
Linker übergeben kann.

[Kaj (Gast)]

Thomas K. schrieb:
> Beim Linken findet avr-gcc.exe die Libraries nicht (cannot find
> -lcmd.h), obwohl diese im Verzeichnis sind
> (H:\foo\TSW\AtmelStudio\cmd.h) und das Verzeichnis in den Optionen
> angegeben ist (-Wl,-L"H:\foo\TSW\AtmelStudio")
> Der Compiler findet alle.
Du weißt aber schon, was eine Library ist, oder?

[Thomas K. (thomaskroger)]

Allgemein:
Wenn jemand eine Fragestellung nicht vollständig durchblickt und in 
einem kompetenten Forum nachfragt, ist es bestimmt hilfreich, dem 
Hilfesuchenden sachdienliche Tipps zu geben.

Es ist für den Hilfesuchenden nicht dienlich, Gegenfragen zu bekommen 
die primär dem Ego des Antwortenden hilft.

Und zur Problemlösung:
Die anderen Kollateralprobleme habe ich im Posting nur ansatzweise 
angedeutet.
Nach einem Update auf die neuste AS-Version läuft es stabil.

Trotzdem danke für die Antworten.

[Oliver S. (oliverso)]

Thomas K. schrieb:
> Allgemein:
> Wenn jemand eine Fragestellung nicht vollständig durchblickt und in
> einem kompetenten Forum nachfragt, ist es bestimmt hilfreich, dem
> Hilfesuchenden sachdienliche Tipps zu geben.
>
> Es ist für den Hilfesuchenden nicht dienlich, Gegenfragen zu bekommen
> die primär dem Ego des Antwortenden hilft.

Nun ja, man kann den Hinweis, daß es völliger Blödsinn ist, 
headerdateien als libs zu linken, sicherlich unterschiedlich 
formulieren. Blödsinn bleibt es trotzdem.

Und wenn dann der Klassiker "das hat schonmal funktioniert" kommt, zeigt 
das die völlige Ahnungslosigkeit des Fragenden. Drauf wird die Antwort 
dann angepasst.

Oliver

[Thomas K. (thomaskroger)]

> Und wenn dann der Klassiker "das hat schonmal funktioniert" kommt, zeigt
> das die völlige Ahnungslosigkeit des Fragenden. Drauf wird die Antwort
> dann angepasst.
> Oliver

Hallo Oliver,
wie ich schrieb: "Es funktionierte jahrelang mit Make auf WinAVR." ist 
keine Garantie, dass es auch mit der AS-Toolchain funzt. Und genau 
darauf bezog sich meine Frage.
Wir Menschen unterscheiden uns in dem was wir wissen, wir sind alle 
gleich in dem was wir nicht wissen.

Es ist schade, dass Hildesuchende durch solche obsolten Diskussionen vom 
Posten abgeschreckt werden.

Ich schlage vor, dass wir den Thread hier schließen, da für Suchende nix 
Neues dabei herum kommt.

mny tnx.

[Kaj (Gast)]

Thomas K. schrieb:
> "Es funktionierte jahrelang mit Make auf WinAVR." ist
> keine Garantie, dass es auch mit der AS-Toolchain funzt. Und genau
> darauf bezog sich meine Frage.
Das kann noch nie Funktioniert haben!
Aus dem einfachen Grund, weil eine Headerdatei keine Lib ist!

(Nebenbei: Die Atmel-Toolchain nutzt auch make und den gcc und blah 
pipapo. Wenn es angeblich mit make und WinAVR ging, geht es auch mit der 
Atmel-Toolchain.)


Und ich frage nochmal: Weißt du überhaupt was eine Lib ist?

Wenn du es weißt, frage ich mich, weshalb du versuchst dem Linker eine 
Headerdatei zu übergeben.

Die interessante Frage ist jetzt aber:
Ist dein -l ein kleines L oder ein großes i?

Wenn du sagst, das es mit make funktioniert hat, dann gehe ich davon 
aus, das es ein großes i sein soll für den Include-Pfad.

Mit einem L (egal ob groß oder klein) kann es aber nie funktioniert 
haben, denn das ist zum Linken von Libs. Ein -l (kleines L) macht aus 
deinem xyz.h ein libxyz.h.a

So, anstatt zu weinen, wie ungerecht und böse diese Welt doch zu dir 
ist, könntest du auch einfach mal Fragen beantworten! Denn dir wurde 
sehr wohl geholfen, nämlich hier

Peter II schrieb:
> Thomas K. schrieb:
>> -lcmd.h
>
> was soll das darstellen? eine Headerdatei ist doch keine lib die man den
> Linker übergeben kann.

und auch von mir, hier:

Kaj schrieb:
> Thomas K. schrieb:
>> Beim Linken findet avr-gcc.exe die Libraries nicht (cannot find
>> -lcmd.h), obwohl diese im Verzeichnis sind
>> (H:\foo\TSW\AtmelStudio\cmd.h) und das Verzeichnis in den Optionen
>> angegeben ist (-Wl,-L"H:\foo\TSW\AtmelStudio")
>> Der Compiler findet alle.
> Du weißt aber schon, was eine Library ist, oder?

An diesen beiden Stellen hättest du erkennen können, wenn du es denn 
gewollt hättest, das Du ganz vielleicht eventuell irgendwas falsch 
gemacht hast. Und dir wurde sogar gesagt was:
Du versuchst dem Linker eine Headerdatei zu geben, wobei Du die ganze 
Zeit von einer Library redest... Eine Headerdatei ist aber KEINE 
Library.

Ein -lcmd.h macht daraus ein libcmd.h.a... und natürlich existiert diese 
Datei nicht.


Dir wurde hier Hilfe zur Selbshilfe gegeben, offenbar willst du aber gar 
keine Hilfe... okay, warum fragst du dann überhaupt?


Hier mal einfach der Auszug aus man ld zu den Optionen l und L

       -l namespec
       --library=namespec
           Add the archive or object file specified by namespec to the list of files to link.  This option may be used any number of times.  If namespec is of the form :filename, ld
           will search the library path for a file called filename, otherwise it will search the library path for a file called libnamespec.a.

           On systems which support shared libraries, ld may also search for files other than libnamespec.a.  Specifically, on ELF and SunOS systems, ld will search a directory for a
           library called libnamespec.so before searching for one called libnamespec.a.  (By convention, a ".so" extension indicates a shared library.)  Note that this behavior does
           not apply to :filename, which always specifies a file called filename.

           The linker will search an archive only once, at the location where it is specified on the command line.  If the archive defines a symbol which was undefined in some object
           which appeared before the archive on the command line, the linker will include the appropriate file(s) from the archive.  However, an undefined symbol in an object appearing
           later on the command line will not cause the linker to search the archive again.

           See the -( option for a way to force the linker to search archives multiple times.

           You may list the same archive multiple times on the command line.

           This type of archive searching is standard for Unix linkers.  However, if you are using ld on AIX, note that it is different from the behaviour of the AIX linker.

       -L searchdir
       --library-path=searchdir
           Add path searchdir to the list of paths that ld will search for archive libraries and ld control scripts.  You may use this option any number of times.  The directories are
           searched in the order in which they are specified on the command line.  Directories specified on the command line are searched before the default directories.  All -L
           options apply to all -l options, regardless of the order in which the options appear.  -L options do not affect how ld searches for a linker script unless -T option is
           specified.

           If searchdir begins with "=", then the "=" will be replaced by the sysroot prefix, controlled by the --sysroot option, or specified when the linker is configured.

           The default set of paths searched (without being specified with -L) depends on which emulation mode ld is using, and in some cases also on how it was configured.

           The paths can also be specified in a link script with the "SEARCH_DIR" command.  Directories specified this way are searched at the point in which the linker script appears
           in the command line.

Thomas K. schrieb:
> [...] dem Hilfesuchenden sachdienliche Tipps zu geben.
Haben wir gemacht! Siehe oben!

Thomas K. schrieb:
> Es ist für den Hilfesuchenden nicht dienlich, Gegenfragen zu bekommen
> die primär dem Ego des Antwortenden hilft.
Leider kann ich dir nicht persönlich vor 's Schienbein treten, deswegen 
gab es ne Gegenfrage. Gegenfragen haben einen Zweck:
Dich zum Denken zu bewegen... hat leider nicht funktioniert.

Thomas K. schrieb:
> Nach einem Update auf die neuste AS-Version läuft es stabil.
Okay, du hast irgendwas gemacht, und jetzt "funktioniert" es 
irgendwie... das eigentliche Problem hast du aber weder verstanden 
geschweigen denn behoben.