Здравейте колеги, имам проблем с подкарване на отдалечено компилиране.
Разполагам със следната платка: ODROID-C1, Ubuntu 14.04 с изключен графичен режим.

Първите ми проби за тестово подкарване на перифериите бяха на С компилирани с GCC локално на платката през терминален режим. Без проблеми. Сорсовете в обикновен текстов редектор, което върши работа за няколко файла към проект.
Втори етап - да се пише по-високата логика на C/C++ и не мога да подкарам Remoute Compiling/Debuging.

В конкретния случай ми се струва, че крос компилиране не е удачен - защото част от библиотеките които вървят с дистрибуцията за конкретната платка ги няма в стандартната която е на РС-то. Разбира се може да се правят #ifdef _win64 #elif __linux__ .....

Аз го виждам някак така - развойната среда да е на PC-то (Windows) и тя да ползва отдалечено компилатора който е на платката (Ubuntu). Да вижда правилните библиотеки, ако може и да дебъгва. Проекта да си вижда множеството файлове.
Нищо от това не мога да го постигна за сега.

Пробвах Eclips - нещо голяма мъка. Не успях да го накарам отдалечено да стигне до компилатора на платката (Remote System Explorer). Средата и тя бъгава.
Сега тече втори опит с NetBeans. Тъкмо стигнах до слагане на toolchain върху платката и евентуално да сработи отдалеченото компилиране.

Помагайте, че изобщо ми е мъгла как стават тия неща

оф ... кофти ситуация. Ако можеш да избягаш от windows-а бягай. Сценария в който да си ползваш windows за развойна система а target-а да е linux е много трудна за подкарване и най вече безмислена - под windows просто нямаш същото обкръжение или ако го има (cygwin например) е направено с много компромиси. По удачен вариант е да си подкараш една виртуална машина с някакво ubuntu или fedora и в него да подкараш cross tool chain който си върви с дистрибуцията. Но дори и тогава пак не е много лесно защото трябва да имаш инсталирани всички .h файлове на библиотеките които ще ползваш и ги има на този odroid-c1. Общо взето за крос компилация е по удачно да се ползва yocto, openembedded, buildroot, openwrt и т.н. Те си свалят сорсове на всичко - линукс кернел, компилатори и т.н. конфигурират ги за да се създаде build environment според архитектурата на компютъра който ползваш (99% от случаите х86) и след това започват да компилират за target-а който в случая е ARM (но може да е и MIPS, Blackfin, PowerPC, sparc и т.н.) като накрая ти събират ядрото с файлова система готова за качване на SD карта или направо на някой флаш който има на платката (например рутероподобните имат по 4-8-16мб флаш който е напълно достатъчен за дребни приложения).
Предимството на този подход е, че имаш тотален контрол какво се изпълнява и перфектна повторяемост - няма начин да компилираш и да получиш нещо омазано. Разбира се за дребни неща може да компилираш директно на този odroid - щом е с убунту има компилатори но си е мъка, бавно, тегаво и т.н. По добре да ползваш някоя яка х86 машина за да не губиш времето за компилация. Remote debuging не е никакъв проблем - на target-a се пуска gdb server а самото gdb се стартира от build environment-а - там ако ти е кеф ползвай Eclips или VS (има плъгини, платени разбира се). Моя съвет е да инвестираш малко време да се научиш да правиш всичко от конзолата - vim/emacs, make, autotools, gcc, gdb и т.н. Ще ти отнеме по малко време отколкото да се опиташ да подкараш всичко там където си свикнал Не си първия човек който минава по този път така, че има достатъчно ресурси откъдето да търсиш помощ - било то разни сайтове и блогове, било то лично от някой като мен или другите колеги тук във форума - досега не е имало случай да откажем помощ на някого
(разбира се изключвам пишман ученици и студенти които търсят наготово някой да им направи курсовата работа - мечешки услуги да търсят от мечките )

май не е виновен Виндолса а пишман програмистите дето не могат да пишат за Вин...

В случая баш виндоуса е "виновен". Да компилираш линукс под нейтив Уиндоус просто няма как да стане, ако някой го направи ще го призная

Не че обратното е възможно де

Както казва palavarov решението е и на дроида и на работната станция да се търкаля Линукс. Ама имай превид, че и виртуалката не е кой знае какво решение, защото от опит знам, че Убунто под виртуална се влачи ужасно в графичната си част (демек еклипса). Направо е досадно да го гледаш, как мисли при съвсем стандартни графични операции - да местиш джамове например. А лично за мен да чукам по конзолата не е решение, чак толкова олд фешън програмист не съм, хората са ми измислили еклипс, аз да се гърча с vi. Може би някоя друга дистрибуция, Хubuntu или някоя по стара Ubuntu версия е по - удачно решение.

При всички положения забрави за Уиндоуса, единствения вариант да компилираш там е през циганина, ама това пък вече е тотална мъъъъъъка.

аз си признавам, че никога не съм компилирал (*unix) система под еклипс. правя го с мейк.
и няма никакъв пробле във въртулака (vbox) да качиш x86 unix, на който да крос-копилираш за АРМ примерно.
виж, пакетите все още не мога да ги дялкам крос - трябва да са на нейтив машина => необходим е диск на таргета.

и какво му е на vi-то? има го на абсолютно всички инсталции и е абсолютно едно и също навсякъде.
е, има и по-шарена версия vim, но командите са същите.

То еклипса в случая е просто редактор. Даже и индексирането му според мен ще се насере тотално ако му подадеш линукс сорсовете. Ако дебъгера тръгне ще е някакво върховно чудо, ама то хардуерен дебъг под линукс си е ....

Та еклипса ти трябва колкото да оцвети кода, да ти засветва скобите и да скачаш между дефинициите (ако успее да ги индексира) и .... май толкова Ма пак не е малко, ако човек пише голям обем код, с тоя vim е просто кретенска мъка. Това е удобно за патчване и компилиране на готов код, а не за разработка на нов. Това, че го има на всички инсталации е точно с цел да се човърка, а не да се изгража голям обем код с него.

Не, че не познавам хора които пишат изначало на vim. Ама аз много странни птици познавам

Аз работя изцяло под Линукс, но въпреки това от известно време минах на chroot/виртуални машини в които са ми настроени тулчейновете и билд системите за крос компилация. Иначе като решиш да си ъпгрейднеш до най-новата версия дистрибуцията за някоя глезотия или защото си си купил нов компютър се губи много време, докато натаманиш пак всичко. А за някои по-стари и неразвиващи се системи е и невъзможно да подкараш инструментите за разработка на текуща версия на дистрибуциите.



Какви пакети правиш и ползваш ли някаква билд система? По принцип билд системите предназначени за ембеддед разработка си правят без проблем АРМ (ipk, deb, rpm) пакети на х86 машинa.

Иначе ако ребилдваш пакети от нормална десктоп/сървър дистрибуция като Дебиан, действително много от тях въобще не са предвидени за крос компилация. В тоя случай най-лесния начин си е нейтив билд.

То хост-а дали ще е линукс или не, все си е крос-компилиране. Ти библиотеките можеш да си ги имах на линукс хоста, ама не ти вършат работа по много причини - друга архитектура, други версии. И объркването да се "замаже" и да те вкара в по-голям филм.
Имам предвид че щом ще е крос, няма значение какъв е хоста. Все ти трябва toolchain за целта. Не споря че организирането е по-лесно ако хоста ти е линукс (и познаваш линукс което обаче е задължително ако ще компилираш за линукс ). То повечето улеснения са от това че някой вече е минал по този път и преборил проблемите.
Преди години ползвах OpenEmbedded под линукс хост. Напоследък ползвам crosstool-ng и ptxdist. От последното (ptxdist) колегите някак са изкарали toolchain дето тича на windows хост. Е, кърнела го билдват май още под линукс, ама за разните ни приложения ползваме вин варианта. Като имаш компилатор и хедърите (и статичните библиотеки) нямаш пречка да компилираш под виндоус.
А и за дебъг-а - ми то винаги си е remote debug през gdbserver. Няма голямо значение дали тоя сървър го ползваш от линукс или вин хост. Еклипса се справя чудесно с "индексирането" на сорса - само трябва да си наясно с "provider"-ите дето дават информацията за системните хедъри и/или да си организираш (Preferences->C/C++ General->Paths and symbols и Preprocesor include paths).
Другото важно с еклипса (и не само) е да не се изкушаваш да слагаш toolchain-ове в path променливата на системата/профила на потребителя. Спестява много омазвания (при крос компилиране).
Откъде поръча платката? Pollin нещо цепят глави (44 евра). Директно от hardkernel е 44 долара. Да не би да има друга алтернатива?

Edit: има и друга опция, която все не успявам да вкарам на дневен ред за тест:
http://www.wingdb.com/wgFeatures.htm
Някакви 89 долара е единичния лиценз. Ако ползвате (и имате) за друго Visual Studio е много интересна опция. Имат toolchain-ове и доста добри документации.

И аз така си мислех до преди няколко години ... бях си свикнал с windows, .net, visual studio ... даже и акъл давах на разни линуксаджии, че то разбираш ли продуктивноста като си с IDE обезмисля всякакви мъки в конзолата, те па ме гледаха и ми се усмихваха ... и само по невъзпитаните ми казваха "я оди се гръмни некъде ...".
После реших, че то на микромеките коня е яко в реката и светлото бъдеще е в опън сорса, което общо взето все още си е валидно и започнах да "мигрирам" към линукс. Минах през какви ли не среди - до една калпави и не можещи да се опрат и на малкия пръст на VS - факт. Да не ги изброявам, много са ... Постепенно взе да ми се изяснява, че всъщност прекарвам повечето време в конзолата а не в гуи-то ( в момента на виртуалките въобще нямам гуи ) и е много по удобно ако ползвам някакъв конзолен редактор. VI-то в началото ме същиса - даже не успях да излезна от него че трябваше да убия терминала - ама ме и амбицира ... попрочетох това онова из нета и се оказа, че то си е проектирано съвсем тенденциозно да е така - всичко да се прави само с основния блок на клавиатурата за да не се налага човек да си мести ръцете върху стрелки или мишка (е, всъщност оригинално е било писано за терминала който не е имал нито стрелки нито мишка ама това само злите езици го разправят ... догмата в момента е, че е целта е ергономичност - същата история като как арм изначално е проектиран да е с ниска консумация, а не че това е страничен ефект от допотопната му разработка му и факта, че всичко е правено на ръка та от там малък брой транзистори и евтина технология за производство - абе легенди да има ... децата се впечатляват от приказки) Та след няколко седмици мъка му посвикнах - голям зор е сменянето на дългогодишни навици с нови такива, особенно няколкото режима на работа (команден, редакция, селекция) където всеки клавиш може да има и нов смисъл - но във VIM на практика си има всичко с подходящите плъгинчета - оцветяване, аутокомплийт, викане на мейк и скачане от грешка на грешка след това, интегриран гит ... ако някой ме гледа от страни как ръцете ми шарят по клавиатурата ще ме помисли за тотално откачен, а всъщност съм леко напреднал, далече съм още от майстор джедай - но все пак, чупя екрана на няколко парчета, вкарвам различни файлове в тях, скачам от сесия в сесия със screen. Струва си отвсякъде ако човек иска да работи с ембедед устройства да е винаги в една и съща среда ... Друг аргумент е, че за ембедед линукс писането на код е много по малко от ровенето в чужд код - а там единственото което помага е добрия стар grep в комбинация със cscope/ctag ... така мога да се навигирам из сорсове на няколко библиотеки + линукс кернел + инит скриптове ... и това работи като пушка, докато ide-тата клякат още в момента в който трябва да добавиш външни сорсове които нямат общо с техния проектен файл, камо ли да парснат целия линукс кернел - мъка ...

Въпрос на това кое познава човек. Никой не е казал че IDE-то трябва да замени всички други инструменти. И досега за някой неща ми е по-удобно за ползва tortoisesvn отколкото еклипската перспектива за синхронизиране. Но го отдавам на това че костенурката съм я ползвал много години. Но от друга страна това не ме кара да работя с subversion от командния ред.
От друга страна никой не те спира да си имаш отворена конзола отделно, или вътре в еклипса и да си командваш оттам.
Тая тема е дискутирана много пъти, за мен интерфейс дето е проектиран и правен за 1920х1200 дава повече информация и предполага по-удобна работа от конзола. Мишка + клавиатура е повече от само клавиатура ... Т.е. и в Eclipse-а има shortcut-и колкото искаш, ако желаеш можеш да ги научиш и да ги ползваш.
И да, кърнела на линукса сигурно ще постави на колене еклипса и анализаторите му. Ма то е логично - кой нормален проект съдържа толкова код? Ако говорим за ембеддед линукс кърнел, доста малка част от сорса реално влиза в крайния проект, сигурно 90% са ifdef-нати от config-а да ги няма. Което е логично от гледна точка на build системата им и подхода им, но не мисля че е най-удобния вариант. Не виждам логика целия ти source tree на всичко възможно да ти е накуп. За чий ми са примерно нещата за x86 ако ще правя арм? Или няколко хиляди неизползвани от мен драйвера? Що трябва да тегля 500М сорс примерно? Но това си е друг подход. Май "submodule" на git-а са за това.

Едит: доколкото разбирам и ти жулиш да IDE - само че твоето е конзолно и се казва VI ...

И пак едит: да не би мейкфейл, оп, мейкфайл базираните неща да се оправят със сорс извън описанието (проекта) им? Ако на еклипс ти трябва да вкараш нещо голямо и чуждо ( ), импортирай в нов проект цялата му папка и можеш да ровиш.

Мерси за насоките, ще ги огледам да добия представа.
Още ме влече към идеята да може да се работи върху желязото през remoute заради кривите библиотеки когато няма направен toolchain. Може и да не става на този етап или да има други ограничения, тия неща са ми нови и мъгляви.


Директно от hardkernel. Все още ценово си струва преди да се се изравнили USD/EU че и след това. Пристига на адрес. Имам информация, че след около две седмици ще се появи малко количество от въпросната платка в нашенска фирма за свободна продажба и някакви периферни джаджи като LCD, WiFi, Bluetooth, Audio и други, но не знам подробности. Цената щяла да е като немската.

Иначе опитът показва, че със SDcard под 8 GB не е комфортно при разни експерименти.

Да, освен това трябва да е бърза картата.

Някои го наричат *nix shell IDE

Става въпрос за гледане на сорса, не за буилдване - искаш да викнеш някоя функция от външна библиотека която не работи както е документирано ако въобще е документирано - и ако тази функция вика друга функция от друга библиотека става весело