Diskuze: Absence spustitelných souborů v IDE pro C
V předchozím kvízu, Online test znalostí C++, jsme si ověřili nabyté zkušenosti z kurzu.

Člen

Zobrazeno 25 zpráv z 25.
V předchozím kvízu, Online test znalostí C++, jsme si ověřili nabyté zkušenosti z kurzu.
Docela určitě je generuje
. Jen je musíš najít někde v té adresářové struktuře
Díky za upozornění .Nedodržel jsem netečkovou tradici psaní jmen adresářů a souborů .A tady se to projevilo .Znaky za tečkou byly chápány jako přípona ,takže "exe" odpadlo .Když už je spuštěno vlákno ,chtěl bych se ještě zeptat ,jak odstranit jednu nefunkčnost .Když spustím "exe" soubor (poklepu na něj) ,otevře se okno a hlášení ,že nelze najít soubor "cygwin1.dll" a mám zkusit přeinstalovat program .To jsem zkusil 4-krát(Cygwin64Terminal) ,1-krát NetBeans IDE 8.2 64 bit a chování bylo pořád stejné .Přitom soubor "cygwin1.dll" ve vytvořeném adresáři "cygwin64" je v podadresáři "bin" .Setkali jste se s něčím takovým ?
Nechápu, kde ten soubor je. Ale zkus ho dát do stejného adresáře jako je ten .exe
Díky za radu .Už to funguje .Je sice nepraktické dodávat ke spustitelnému souboru další soubor ,který má 3Mbyte ,ale je to řešení .
Myslím, že by to mohlo jít zalinkovat do jednoho souboru. Nevím, jak, předtím, než se zeptáš.
Pokud ti stačí zatím program spouštět jen na svém stroji, můžeš nakopírovat cygwin1.dll do systémového adresáře (Windows\system32). Pak jej nemusíš mít ve stejném adresáři jako to .exe, protože si jej systém v případě potřeby najde sám.
Ono i když jej staticky slinkuješ s tím. exe (což si moc nejsem jistý, zda půjde, pokud k němu nemáš .lib/.a soubor), tak nemusíš moc ušetřit, co se týče místa. Nejideálnější by bylo se toho cygwinu zbavit úplně, pokud ohldáš pracovat na Windows.
Zkoušel jsem nakopírovat cygwin1.dll do doporučovaného systémového adresáře (Windows\system32) ,ale nepomohlo to ."Exe" soubor jej nenašel .Asi je potřeba někde nastavit správnou cestu .Explicitně jde dynamický soubor nalinkovat údajně v Linuxu(přípona .so dynamického souboru) ,ale jak říkáš ,i kdybych ho připojil ve Windows ,tak prostorově neušetřím .Ale ta 1.varianta se systémovým adresářem mne zajímá ,jen nastavit správně přístup .Nejlepší by skutečně bylo se toho cygwinu úplně zbavit ,ale jak ?
To je divné, ověř si zda máš windows\system32 mezi PATH (v nastavení systémových proměnných).
To je divné, ověř si zda máš windows\system32 mezi PATH (v nastavení systémových proměnných).
To by nemělo být potřeba. Když systém hledá DLL knihovny, tak se do systémového adresáře obvykle dívá dříve, než do PATH.
jen nastavit správně přístup
Ještě mě napadá, že ti třeba nesedí "bitovost" té cygwin1.dll. Pokud je 64bitová, musíš ji dát do Windows\system32, pokud 32bitová, tak do Windows\sysWOW64. Na 32bitových Windows není co řešit, tam je to vždy Windows\system32. A ještě pozor na to, že pokud bys to kopírování dělal v 32bitové aplikaci, která na to není připravena, tak pro ni bude Windows\system32 ve skutečnosti shodný s Windows\sysWOW64 (pro přístup do system32 je třeba explicitně jít do Windows\sysnative).
Nejlepší by skutečně bylo se toho cygwinu úplně zbavit ,ale jak
Já nevím právě, zda v Netbeans musíš ten cygwin1.dll využívat, nebo ne (jinak řečeno, jak moc někdo du kompatibilitu s Windows odflákl a místo, aby si trošku zaprogramoval, použil cygwin1.dll). Pokud píšu aplikace, co mají být přenositelné i na Linux, tak je obvykle tvořím ve Visual Studiu a pro linuxové použití k nim dělám Makefile. Je to asi trochu pracnější, ale poměrně bezproblémové.
Explicitně jde dynamický soubor nalinkovat údajně v Linuxu(přípona .so dynamického souboru)
.so v Linuxu = .dll ve Windows.
ale jak říkáš ,i kdybych ho připojil ve Windows ,tak prostorově neušetřím
Ušetřil bys v případě, kdybys měl k té knihovně statickou verzi (.lib soubor, ale ne ten navázaný na DLL knihovnu). Pak je linker schopný do výsledného .exe souboru nezahrnout rutiny, které z té knihovny nepoužíváš, což může, ale nemusí, výrazně pomoci.
Díval jsem se do SysWOW64 a tam se cygwin1.dll nakopíroval automaticky také .Pak jsem cygwin1.dll nakopíroval ještě do Windows\sysnative jak píšeš a to pomohlo .Nyní jde spustit .exe soubor bez přikopírování cygwin1.dll do jeho adresáře .Takže díky .Statickou verzi souboru cygwin1.dll asi neseženu ,tak se musím smířit s tím ,jak to je .Ještě by mne zajímalo ,kde se nastavují systémové proměnné ,hledal jsem autoexec.bat ,jak se to dělalo dříve ,a v adresáři Windows jsem navíc nenašel žádný .bat soubor .
Ano, pokud lezeš do systémových adresářů z 32bitová aplikace, která na to není připravená, system32 a sysWOW64 vedou do stejného adresáře (konkrétně právě do sysWOW64). Nejedná se v tomto případě o symlink, ale nižší vrstvy systémových knihoven automaticky překládají system32 na sysWOW64.
autoexec.bat
autoexec.bat je už hodně dlouho jenom tak pro okrasu, tzn. nepoužívá se pro nic.
proměnné prostředí
Pro nastavení proměnných prostředí můžeš využít grafické orzhraní v Ovládací panely -> Systém a zabezpečení -> Systém -> Upravit nastavení systému -> Upřesnit. A tam je tlačítko Proměnné prostředí.
Díky za vysvětlení a za pokyny .Předpokládám ,že nemáš podobné problémy jako já ,takže bych se zeptal ,jaké používáš IDE pro C-éčko ,kdybych byl v budoucnu donucen pro jeho změnu .
Díky za vysvětlení a za pokyny .Předpokládám ,že nemáš podobné problémy jako já ,takže bych se zeptal ,jaké používáš IDE pro C-éčko ,kdybych byl v budoucnu donucen pro jeho změnu .
Visual Studio (aktuálně 2017 Community). Pokud chci něco rozjet i pod Linuxem, tak si ručně napíšu Makefile a kompiluju to z příkazové řádky.
Visual Studio můžeš použít i pro C. Při pojmenování souboru programu je avšak třeba dodržet koncovku .C a nikoli .CPP. Je to důležité. Na základě koncovky souboru překladač vyhodnocuje, jak má daný program přeložit. Ne každý program napsaný v C je platný program v C++. Pokus přeložit program v C jako by to byl program v C++ způsobí v některých případech chybu.
Díky za radu .Funguje to .A všem děkuji za celé vlákno .Pavel .
Je to důležité. Na základě koncovky souboru překladač vyhodnocuje, jak má daný program přeložit.
Tohle jde změnit v nastavení projektu (explicitně určit, zda se jedná o
C či C++), ale souhlasím, že je nejlepší nechat to na té příponě .
stejně na tom je třeba simutrans (než přešel na steam, nevím jak
dnes).
SDL DLL musí být u exe, jinak nejede (nebo někde, kde na to win uvidí)
Co vím, tak by na to měli být také podobně openTTD a supertux.
Docela by mne zajímalo explicitní nastavení projektu pro určení volby C nebo C++ ve Visual Studiu .Tedy jestli je možné ,aby IDE od začátku pracovalo s C .
Tohle jde změnit v nastavení projektu (explicitně určit, zda se jedná o C či C++), ale souhlasím, že je nejlepší nechat to na té příponě .
Také možnost. Užitečné zejména pro ty co importují již hotové
(převážně cizí) zdrojové kódy. Pro ostatní je volba kompilace kódu
daného jazyka při vytváření zdrojového souboru změnou přípony mnohem
komfortnější.
Toho lze dosáhnout vytvořením šablony s navoleným druhem kompilace v
daném jazyce a tu následně používat při tvorbě nových projektů. Je to
pohodlné, úspora času je ale minimální a smaže se při první delší
myšlence.
Buď šablonou projektu, nebo to můžeš (ve Visual Studiu) dodefinovat i prostřednictvím tzv. Property Sheetů. To jsou soubory, které aplikují dané změny do nastavení projektu, přičemž je můžeš aplikovat pro všechny konfigurace (Release, Debug) a platformy (x86, x64, ARM, ARMv64, ...), nebo třeba jen pro nějakou podmnožinu z nich. Samozřejmě, u volby jazyka (C/C++) nedává aplikace jen na podmnožinu moc smysl, ale jsou nastavení, kde to naopak velmi dobrý smysl dává (oddělné ukládání souborů, speciální chování pro některé typy projektů atd.).
Zobrazeno 25 zpráv z 25.