Gtkmm pro Windows x64 (diskuse)

[=^..^= AmigaPower®]

Stable release msys je na Vistě x64 absolutně nestabilní a tak jsem byl nucen stáhnout nestabilní, která byla stabilní

+1

...ty pokud neprovokuješ rejpánim do linuxu, tak jsou tvoje zápisky celkem hodnotné, hodnotím: dobré

[Miloslav Ponkrác]

Jakožto programátor s dvacetiletou praxí tvrdím pořád totéž: Kompilaci má provádět vývojář, nebo vývojový tým, který daný program/aplikaci/produkt provádí. Zbytek má používat zkompilované věci od vývojového týmu. Kdokoli jiný bude akorát držkovat, a navíc je pravděpodobné, že to neudělá tak dobře, jako vývojáři sami. Dokonce i v řadě Bugzill je řada bugů, které mají dovětek: "Bug se objeví pouze při špatné kompilaci".

[Grunt]

Zajímavý názor. Co jenom je na tomto diagramu špatně? Ono se to nejmenuje Open Source Software jen tak.

[Miloslav Ponkrác]

Open source nevylučuje to, že to zkompiluje programátor. Open source je, abych Vás tedy poučil, když to chccete vědět zkratka pro "otevřený zdrojový kód", tedy že ho máte k dispozici, můžete ho studovat, ale není zde nutně řečeno, že user ho musí kompilovat - nemusí. A v 99% také ani nekompiluje už proto, že většina userů to nezvládne, a nebo to nechce dělat.

Podle mého by běžný user neměl kompilovat. Kompilace by měla být až poslední nouzová věc, když selhalo použití binárek připravených vývojovým týmem, a nebo je tým výrazně zprasil (stává se to, ale je to asi 1000x méně pravděpodobné, než to, že je zprasí BFU neodbornou kompilací).

Zdrojové kódy mají sloužit k tomu, aby se do nich dalo nahlédnout, aby se jimi dalo inspirovat. Aby je bylo možné zkompilovat pro nepodporovanou platformu - čímž odpovídám na příspěvek níže, ale to málokdy bez přeprogramování a úpravy programu jde zcela bez potíží, takže zase utopie, že to udělá BFU. A také proto, aby se nich dal odvodit nový projekt, či fork. To všechno je původní určení source code. Pokud se ovšem kompiluje jenom proto, aby se kompilovalo, a člověk si mohl poplácat po ramenou, že dokáže zkompilovat zdroják, to je tedy borec - tak to považuji za hovadinu.

[Jardík]

Doprdele, když mi asi nenabízí 64bit binárku pro Windows, tak si ji musím zkompilovat sám a nebo utřít prdel.

[default]

Klííd. Já si osobně myslím, že free a open source software se primárně dodává jen ve zdrojové formě. Jakékoli binárky jsou jen bonusem.

A to, že configure scripty jsou nedodělaný či nezdokumentovaný, to je tak trochu proti licenci. Četl jsem právní rozbor OSS licencí, a prý z nich vyplývá, že se má k produktu vždy dodávat návod, jak to zkompilovat.

Takže pláčete správně, ale na špatném hrobě

[...............23]

A čo ak sa vývojári neunúvajú vydať build pre niektorú platformu? Tam moc možností neni...

Inak je fakt že by som uvítal nejaký package management system na knižnice pre msvc a mingw, aspoň niečo ako má cygwin... Proste ako v archu, potrebujem napríklad lua, napíšem pacman -S lua a je to, zatiaľ čo vo windows to je treba kompilovať a ručne upgradovať...

[Grunt]

Inak je fakt že by som uvítal nejaký package management system na knižnice pre msvc

Zas tak moc to s tím masochismem nemusíme přehánět.

a mingw, aspoň niečo ako má cygwin...

A jaký je rozdíl mezi Cygwinem a balíkovacím systémem pro MinGW?

BTW: Cygwin má i binárku rpm, takže když si uděláte repositář, aneb proti gustu…

zatiaľ čo vo windows to je treba kompilovať a ručne upgradovať...

To bude spíš tím, že kompilovat binárky pro Windows se moc nikomu nechce.

[...............23]

Inak je fakt že by som uvítal nejaký package management system na knižnice pre msvc

Zas tak moc to s tím masochismem nemusíme přehánět.

Je to oveľa pohodlnejšie než to inštalovať ručne. Veľa knižníc síce ponúka binárky pre msvc, ale to treba ručne sťahovať a pchať do jedného adresára (alebo nastavovať milión ciest ku knižniciam) a potom je tam bordel.

A jaký je rozdíl mezi Cygwinem a balíkovacím systémem pro MinGW?

Že mingw tam má dokopy jeden a pol balíka...

To bude spíš tím, že kompilovat binárky pro Windows se moc nikomu nechce.

Pre väčšinu knižníc sú binárky k dispozícii, takže to asi nebude moc pravda... Síce nie vždy priamo od autora, ale použiť sa to väčšinou dá...

[Grunt]

Je to oveľa pohodlnejšie než to inštalovať ručne. Veľa knižníc síce ponúka binárky pre msvc, ale to treba ručne sťahovať a pchať do jedného adresára (alebo nastavovať milión ciest ku knižniciam) a potom je tam bordel.

Počkat, bavíme se o MSVC?

Že mingw tam má dokopy jeden a pol balíka...

A MinGW má někde balíky? A pokud ano, tak kde prosím. Něco mi muselo uniknout.

Pre väčšinu knižníc sú binárky k dispozícii, takže to asi nebude moc pravda... Síce nie vždy priamo od autora, ale použiť sa to väčšinou dá...

Jenže je rozdíl mezi binárkami knihoven a binárkami knihoven určitých verzí s určitými zakompilovanými funkcemi. A bavíme se o GNU a né o komerčním softwaru. I když teda uznávám, že situace se poslední dobou výrazně zlepšila.

[...............23]

Počkat, bavíme se o MSVC?

To je jedno, msvc a mingw to majú vyriešené v podstate rovnako, a skompilované knižnice sú tiež väčšinou dostupné pre obe...

A MinGW má někde balíky? A pokud ano, tak kde prosím. Něco mi muselo uniknout.

To, čo sťahuje a inštaluje ten automated installer, a dá sa to neskôr doinštalovať (väčšinou len časti kompilátora) sa dá považovať za balíky , ale moc tam toho nie je...

Jenže je rozdíl mezi binárkami knihoven a binárkami knihoven určitých verzí s určitými zakompilovanými funkcemi. A bavíme se o GNU a né o komerčním softwaru. I když teda uznávám, že situace se poslední dobou výrazně zlepšila.

Nj, ale mne väčšinou stačia nejaké základné featury, nepotrebujem napr. SDL s podporou výstupu cez aalib a podobné hovadiny... Plus niektoré knižnice už vedia načítať dostupné "pluginy" dynamicky, takže tam tento problém odpadá...

[Grunt]

To, čo sťahuje a inštaluje ten automated installer, a dá sa to neskôr doinštalovať (väčšinou len časti kompilátora) sa dá považovať za balíky

To jsou jen binárky aby bylo kompilační prostředí kompletní a nebo jako pomocné programy(wget,tar,&ehellip; - kdo to má také pořád tahat ve FireFoxu a rozbalovat ve WinRaru). Ono se to Minimal SYStem nejmenuje jen tak pro radost.

ale moc tam toho nie je...

Není nic jednoduššího než zkompilovat a zveřejnit.

Nj, ale mne väčšinou stačia nejaké základné featury, nepotrebujem napr. SDL s podporou výstupu cez aalib a podobné hovadiny...

Jenže nejde o to, co stačí Vám, ale co chtějí různé programy a knihovny. Ty většinou brblají, že jim schází nějaká funkce.

Plus niektoré knižnice už vedia načítať dostupné "pluginy" dynamicky, takže tam tento problém odpadá...

To je zas proboha co? A radši to nechci ani vědět.

[Miloslav Ponkrác]

To je jedno, msvc a mingw to majú vyriešené v podstate rovnako, a skompilované knižnice sú tiež väčšinou dostupné pre obe...

Tak myslím, že tohle stačí. msvc a mingw jsou totálně rozdílné prohlížeče, které to mají vyřešené každý v mnoha ohledech dost jinak. Řada zkompilovaných knihoven (pokud nezůstanete u jednoduchého C) není zcela přenositelná mezi nimi a C++ už vůbec. Důvod, proč to někdy trochu jde je ten, že mingw používá jako runtime knihovnu ukradenou runtime knihovnu ze stařičkého Microsoft Visual C/C++ 6.0 (pro představu přes deset let starou), a to je tak všechno. Mezitím prošel MSVC řadou dalších verzí a je úplně jinde.

Msvc je prostě kompilátor microsoftu, mingw je windows port gcc. Totálně rozdílné překladače.

[default]

To bude spíš tím, že kompilovat binárky pro Windows se moc nikomu nechce.

Ani se nedivím. Kvůli jednomu baťáku (můj aktuální případ) fakt licenci kupovat nebudu. A bash.exe s tunou DLL fakt k programu v Javě dodávat nehodlám. Tak holt smůla

[Max]

To je sice pěkné, ale bavilo by tě připravovat balíčky pro x desítek distribucí? Pro různé platformy? Asi moc ne, protože by jsi tím přišel o hodně moc času. Navíc když by jsi si představil, že jsi zapojen ve více projektech, tak už by to byl přímo horor.
Jinak pravděpodobnost toho, že vývojář onoho sw připraví lepší balíček, nežli nějaký balíčkář, je stejně tak velká jako že balíčkář ho připraví lépe, nežli samotný tvůrce programu. (programátor nemusí rozumnět různým balíčkovacím systémům, distribucím atd.)
Zdar Max

[nhy]

Niekto tu je masochista

[Grunt]

Stable release msys je na Vistě x64 absolutně nestabilní a tak jsem byl nucen stáhnout nestabilní, která byla stabilní

Což je doporučováno i v samotném návodě.

Jenže to se nedá říci o glibmm, která při linkování má milióny "undefined reference to *".

Aneb vítejte v kompilačním prostředí systému Windows. Ono překladač a BASH jsou jen začátek a ke kompletnímu a hlavně funkčnímu GNU Build systému vede ještě docela dlouhá a trnitá cesta. Doporučuji alespoň omrknou další kýble předkompilovaných knihoven/programů a také původní Enlightenment Wiki.

Vidím to spíše na nějaký bug v gtkmm, na nějaký hnusný typecast z pointeru na long (který je jako int na Win64 32bitový).

Kdepak. Undefined reference to říká, že v nějakém ze zdrojáků je použitá funkce, která nebyla definována v žádném z vložených hlavičkových souborů. Důvody může být více(určitě jich bude i více než jsem jich napsal, ale tyto mě zrovna teď napadly):

Nesplněné závislosti - nejpravděpodobnější

Ve zdrojácích je použito funkce z nějaké knihovny, ovšem jako závislost je splněna starší verze této knihovny, která tuto funkci, sbírku procedur, datový typ, sadu tříd a bůhvícoještě ve své starší verzi neobsahuje. Prostě špatné API mezi knihovou a programem, které prošlo přes configure skript. Stačí se prostě mrknout, které hlavičkové soubory inkriminovaný zdrojový soubor vkládá, najít ke kterým knihovnám patří a stáhnou novější verze těchto knihoven a zkontrolovat ve které z nich funkce je a tu mu pak před kompilací předhodit.

configure skript není také dokonalý a třeba zapomněl vložit nějakou knihovnu. Postup stejný jako v předchozím případě a pak CFLAGS="-lknihovna"

Hlavičkové soubory jsou jinde než je gcc očekává.(chyba pkg-configu) Postup také stejný jako v předchozích případech a CFLAGS="-L/umístnění/"

A nebo fakt nějaký vývojář udělal chybu a přepsal se třeba v názvu funkce. Ve stabilních vydáních silně nepravděpodobné

Ještě to projedu debugerem a zkusím to opravit.

Ten umí mluvit jen s binárkami.

Když ne nepodaří, tak se na to asi vykvajznu a zkusím Gtk# a Banshee.

Pokud to přeložili vývojáři, znamená to, že to přeložit JDE. Mrkl bych ještě na jejich stránky, jestli tam nějaká dobrá duše nenechala nějaké HOW-TO nebo alespoň nějaká upozornění pro použitou platformu.

Aplikace funguje, dokonce má i ten clearlooks skin, jenže po zavření hlavního okna nastane segmentation fault.

A to je právě většinou důsledek toho špatného API(v tomto případě spíše asi ABI) mezi programem a knihovnami.

[...............23]

Undefined reference je chyba linkeru...

[Grunt]

No jo, omlouvám se. Spletl jsem si to a implicitní deklarací. Linkeru zas tak moc nerozumím, takže do toho radši nebudu kecat. I když to mi dělalo, když jsem vložil novější hlavičkový soubor a měl k dispozici starší verzi statické knihovny.

[...............23]

A väčšinou stačí pozrieť na to aké funkcie tomu chýbajú a upraviť build skript (buď samotný makefile alebo libtool súbor (kto preboha vymyslel autotools?! )) aby prilinkoval danú knižnicu... U statických knižníc niekedy záleží aj na poradí, ale myslím že tam chyba nebude...

[Grunt]

kto preboha vymyslel autotools?!

+1

Také s tím zrovna bojuji. A s autotools to ještě jde, ale co like autotools scripts? Agrh, to je teprve to pravé peklo.

[Grunt]

Ještě jsem zapoměl dodat, že jde i vytvořit toolchain s HOSTujícím systémem třeba linux a cílovým třeba win32. Sice jsem to v životě nezkoušel, ale také je to jedna z cest.

[Jardík]

Vidím to spíše na nějaký bug v gtkmm, na nějaký hnusný typecast z pointeru na long (který je jako int na Win64 32bitový).

To patřilo k tomu, že to po zavření okna padá (mingw build s vlastním makefile), ale asi jsem to špatně formuloval.