Linux за българи: Форуми

Програмиране => Общ форум => Темата е започната от: go_fire в Nov 02, 2012, 13:00



Титла: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: go_fire в Nov 02, 2012, 13:00
Здравейте момчета и момичета. Аз си умирам да задавам глупави въпроси с елементарни отговори, ама е тъй като не си учил по система. Има един въпрос дето бая време се чудя, но след като вчера Мара ме изобличи, днес се сещам да задам.

И така, много пъти сте си хортували тук за едни оптимизации на гцц за професор. Те доста подробно са си обяснени и в документацията на Гну, коя какво представлява и какви допълнителни параметри приема или какви включва. Не ми е въпроса в това. Това съм го чел уж.

Не ми е въпроса и за ядрото. Там знам къде в .config да ги нахакам и общо взето какъв ефект имат. Пък и рядко си правя свой ядра, само ей така за сърбежа. Въпроса ми е друг.

Понякога, много рядко в Дебиан ми се налага нещо да го транслирам от изходен код. Последно беше една игрица на Марио и разбира се регулярно е17, защото това е най-добрия метод да го имаш. А също така не можеш да имаш Пърл6 по друг начин.

Въпроса ми е, мисля си, че някъде могат да се зададат тези настройки генерално, а не да се подават ръчно на гцц. Не може да не може. Само дето аз не знам къде.


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: gat3way в Nov 02, 2012, 13:36
Това зависи от makefile-овете, но по принцип може да пробваш да ги нашиеш в CFLAGS и/или съответно за линкера в LDFLAGS променливите. Разбира се ако makefile-а е написан грубиански, няма файда от това упражнение.


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: go_fire в Nov 02, 2012, 14:05
Извинявам се, за още по-глупавият въпрос, но в кой файл се настройват CFLAGS и LDFLAGS?


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: gat3way в Nov 02, 2012, 14:51
Това са environment променливи, ако искаш си ги експортвай в .bash_profile или там каквото ти е на шела.


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: Naka в Nov 02, 2012, 15:00
това са шелски променливи.
аз правя така:
Код:
export CFLAGS="-O3 -march=athlon-xp -mmmx -msse -m3dnow -fomit-frame-pointer -funroll-loops -mfpmath=sse  -pipe"
export CXXFLAGS="-O3 -march=athlon-xp -mmmx -msse -m3dnow -fomit-frame-pointer -funroll-loops -mfpmath=sse  -pipe"

но за да се зададат за постоянно трябва да се напишат в /etc/bashrc или в /etc/profile.    всеки път се чудя.
в /etc/bashrc най отгоре ми пише # Environment stuff goes in /etc/profile
та затова редактирам /etc/profile и там се задава например:
CFLAGS="-O3 ....................

и малко по надолу пак в /etc/profile има един ред със всичките променливи
export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC

та там трябва също и да се добави CFLAGS CXXFLAGS ... и т.н.
export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC CFLAGS CXXFLAGS


всеки път се чудя къде и как беше. това е за федора.и то глобално. А само локално само за един потребител трябваше в един скрит файл в хоме дир-а на потребителя да се напише
~/.bashrc    или май  ~/.bash_pofile  ???





Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: go_fire в Nov 02, 2012, 15:29
Много благодаря и на двамата!

Само да попитам Гейта. Какво имаше предвид под „грубиянски“ makefile?


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: gat3way в Nov 02, 2012, 23:54
Едното се изпълнява за шелове с контролен терминал, другото - обратното. bashrc примерно би трябвало изпълни за cronjob който е шел скрипт. bash_profile ще се изпълни когато се логнеш през ssh да речем. Обаче нещата са размити и обикновено едното е направено така че да изпълнява другото. И за мен понякога е объркващо ако трябва да съм честен :)

Грубианския makefile би направил нещо от сорта на:

target:
      cc source.c -o executable

вместо:

target:
      $(CC) source.cc $(CFLAGS) -o executable


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

С autoconf/automake нещата стават още по-забавни...въпреки че го ползвам, вече 3 години се опитвам да схвана диаболичния му замисъл, все още не престава да ме изненадва. Това е вероятно най-голямото GNU чудовище, нещо което би трябвало да е просто е направено УЖАСНО усложнено и с ужасно много дребни детайли. В общият случай ако трябва да дам пример за това как не трябва да се прави каквото и да било, autoconf ще е от първите неща, за които ще се сетя.


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: go_fire в Feb 04, 2015, 16:51
Ще ползвам моя стара тема, за да попитам, така и така съм забравил да я отбележа като решена. Става въпрос за статично свързване. Как се прави това?

Специално в моя случай става въпрос за една много млада програма, толкова млада, че чак е сукалче. Тя ми иска по-нова версия на Кайро, от тази, която имам. Проблем няма. Открих такава в хранилищата, хареса я. Обаче това взе да ми чупи други неща. И идеята ми е, статично да я свържа точно за тази програма и да си върна старата версия, за да си оправя изпочупеното.


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: gat3way в Feb 04, 2015, 21:19
За да я линкнеш статично, ще ти трябват статичните библиотеки, а не .so-тата, нещо което с известна вероятност нямаш. При положение че са налични, в реда с опциите на линкера слагаш -Bstatic преди -lбиблиотека1 -lбиблиотека2 ...

По същият начин може с част от библиотеките да се линкваш статично, с част - динамично, редувайки -Bstatic, -Bdynamic с изброяване на библиотеките с които се линкваш.

Това важи за изпълними файлове, ако билдваш библиотека, там нещата са по-различни.


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: go_fire в Feb 04, 2015, 22:13
Аха, това е добре. Но доколкото разбирам първо трябва да транслирам въпросната библиотека като „статична“, защото казваш, че shared objects не стават. А това как се прави?!


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: gat3way в Feb 04, 2015, 22:35
Не знам какво имаш предвид това "транслиране".

Динамичната библиотека няма как да стане статична, технически погледнато да - вътре имаш машинния код, но липсват разни необходими детайли - като например статичната библиотека, представлява tar-подобен архив, съдържащ .о файлове, за които си има специална именна конвенция, която не следва 1:1 имената на символите в .so-то.

Обратното вероятно е по-възможно, макар че не съм го правил никога. От .a можеш да изкараш object файловете и да ги линкнеш в .so библиотека. Макар че не е сигурно че ще стане, към машинния код в динамичните библиотеки има специални изисквания - трябва да е position independant най-малкото, защото се зарежда на различни (случайни) адреси в адресното пространство на програмите, които се линкват с тях. Това е интересен въпрос в крайна сметка - не знам, не съм се замислял много.


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: go_fire в Feb 04, 2015, 22:54
В българската теория няма понятия компилиране и интерпретиране. Те се предават под общият термин транслиране. Защо са решили така, нямам нито най-малка идея.

Преди няколко години като се опитвах да уча Ц/Ц+1, знам, че имаше нещо май такова: gcc -o hello.c и ставаше на библиотека, а не на изпълним файл. Като идващ от езици като бъзик и ППП, така и никога не хванах аджеба, какво е това библиотека. В моя свят такова понятие не съществува. Няма разлика между изпълним файл и библиотека. Сериозно не знам, какво е това.


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: gat3way в Feb 04, 2015, 23:32
gcc -o hello.c няма да създаде библиотека.

Библиотеката апропо може да бъде изпълним файл. Поне динамичните библиотеки. Това не става наготово, трябва да си го направиш. Смисъл голям естествено няма, поради което почти всички динамични библиотеки на твоята система не се държат като изпълними файлове.


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: go_fire в Feb 04, 2015, 23:51
Понеже съм леко тъп да попитам. Защо да е лошо или нелогично? Например, ако ffmpeg може да се държи като изпълним, защо да си свалям mplayer? Вярно mplayer може да ми прави екранни снимки, може да закача надписи, има статистики, може да рисува върху екрана (например информация или контролни копчета, т.нар. OSD) и още някакви начини. Но, ако просто искам да гледам нещо, защо не?


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: gat3way в Feb 05, 2015, 01:30
Че с ffmpeg не идваха ли разни tool-ове, ето ти изпълними файлове значи.

Въпросът е донякъде идеологически, донякъде чисто технически. Идеологически погледнато, код, който няма да се преизползва и е за пред крайния потребител, няма смисъл да се навира в библиотеки, защото е безсмислено, никой няма да ги ползва тези библиотеки на първо време. Код, който се преизползва (например реализацията на някой видео кодек) има логика да бъде реализиран в библиотека с добре дефиниран и документиран интерфейс. На теория, би могло всеки изпълним файл да бъде реализиран като .so библиотека и някой който просто иска да доразшири нещата, примерно mplayer с функция да ти гаси самсунгския телевизор след края на филма, да се линква към библиотеката и да си вика оттам нещата и да ги *донадгражда*. Това даже звучи добре, напомня бледо на уиндоуските COM дивотии дето бяха много модерни по едно време.

Проблемите с това обаче са много. Такъв начин за интерфейсване с наличния код е прекалено....груб така да се каже, всичко ти е в адресното пространство, имаш си символна таблица и динамичен линкер дето ще ти резолвне викането на функции, ще можеш да викаш всяка функция, поне която е в таблицата, static функциите няма да се виждат де. И тук първия проблем - какво става ако не искаш всеки да ти вика функцията примерно? Имаш два варианта - функцията да е static и да не се "вижда" или да не е static и да се "вижда". Ако е static обаче, тя няма да се вижда от други .c файлове от оригиналния проект и това може да е проблем (gcc има магии за целта, ама това да разчиташ на специфично поведение на компилатора е лоша идея, не е portable).

Съвсем отделно, можеш да искаш тази функция да се вика само при много специални условия, които няма как да се проверят ако просто се линкваш към библиотеката, щото там или викаш или не викаш. В конкретната програма може да има много ясен flow, който да изключва тези неща да стават извън тези условия. Когато някой може да вика каквото си иска когато си иска, нямаш гаранции за това и като резултат кодът ще се раздуе с безумни проверки, за да си сигурен че някой идиот не прави каквото не трябва.

Отделно, потребителските програми прекалено често си променят "поведението", не е като някое добре премислено библиотечно API, така нова версия на програмата-библиотека много вероятно ще чупи това дето я ползва. И ще настане един хубав dependency ад, това чат-пат става и сега, но тогава ще е в размери съпоставими с тези от ерата на win98.

Та затова може би не всеки изпълним файл е библиотека (или обратното зависи откъде го гледаш). А иначе и динамичните библиотеки, и изпълнимите файлове използват един и същ ELF формат.



Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: remotexx в Feb 05, 2015, 04:39
Не казваш каква е програмката - ок
Ами и не казваш с коя ОС ...ма така като гледам си има готови пакети статично "транслирана" Кайро библиотека..
Е за някои дистрибуции поне!

http://www.rpmfind.net/linux/rpm2html/search.php?query=libcairo-static-devel
като гледам теб ти трябват libcairo-static и libcairo-static-devel със всичките им зависимости и линкваш към тях и си готов

инак и е просто и не е чак толкова просто - щото може да се наложи да билднеш нещото статично барабар със всичките му зависимости и те статично. Реално разликата (откъм с/с++) е само във дефиницията - е и линкването е различно: динамичните ще се опита да ги резолвне при зареждане от съответното *.so докато статичните направо си дърпа кода по време на компилация та тука има един трик ако нямаш статичната библиотека но имаш кода да го ползваш директно т.е. не като библиотека само си добавяш пътя до експорт хедърите и по натам все едно е твой код. Това е много опростено де...

инак ако т'ва статично Кайро иска да се линква със libgcc-static тогава програмчето ти ще стане бая голямо  ;)
не е задължително ама понеже не казваш кое е програмчето и ако се наложи да даунгрейдваш и libgcc ще ти се наложи и него т.е. по-новата му версия да линкваш статично...
http://stackoverflow.com/questions/22375920/about-linux-c-static-library

П.П. Обик. разни програми, като skype, firefox и др. предполагам, си билдват всичко вкл. и зависимостите (всичките) статично и затова там само разпъваш архива палиш и тръгваш  ;D
А има и др. вариант с динамично ЗАРЕЖДАНЕ (не е линкване) на подходяща библиотека *.dll или *.so - по мои спомени навремето Оракъл правеха подобни магарии и то от Джава - ама това е само за напреднали  >:D

Малка поправка - Скайпа е skype-dynamic т.е. и те като Оракъл не линкват към никаква библиотека ами по време на изпълнение детектват какво имаш и първо най-доброто т.е. напр. търсят pulse-audio и ако го няма търсят alsa и ако няма напр. ползват PC Speaker или въобще нямаш звук - и ако намерят нещо вече си пренасочват function pointer-ите към него и така..


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: gat3way в Feb 05, 2015, 11:20
То за динамичното зареждане с dlopen/dlsym пак трябва да си билднеш програмата динамично линкната с libdl. Няма кой знае каква философия и е доста често срещана практика когато искаш да реализираш плъгини към програмата. Примерно apache така си зарежда dso-тата, php така си зарежда библиотеките дето не са вградени и т.н.


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: go_fire в Feb 05, 2015, 11:47
Благодаря Гейт. Много от нещата дето говориш са ми над развитието, но като от части да схванах идеята.

Като спомена COM та се сетих за Шошон. Той веднъж пусна една статия, в която се обяснява на широко, че той си е жив и здрав до ден днешен, но сега е погребан под слой наречен RT. Реално, който пише за тази платформа, все още го ползва, но с надстроики и не прилича на себе си.

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

---

Ремо, щях да пиша широко за това програмче, ако го бях подкарал. Снощи, което ми се явява май пети ден, се отказах. Обикновенно не казвам имена на програми, за да са ми по-общи питанията и да влязат в работа и на друг ламер. Но щом си любопитен, ще споделя. Пък и статия явно няма да има.

Програмчето е това:

http://fifth-browser.sourceforge.net

Както казах сукалче е, толкова е младо, че няма половин година. Попита за ОС, ГНУ/Линукс (в моя случай Дебиан). Не се занимавам с BSD, макар да съм набрал на Ред Хат и да има такова евентуално бъдеще. Засега винаги е ГНУ/Линукс. Е го Сатир мигрира.

Причината да ми стане интересно програмчето е, че потребява памет, колкото Опера 7-9 да речем. Това ме изуми за съвременен интернет-навигатор. Но няма никаква тайна. Програмчето е писано на Ц++0х (нали така се казваше последната версия?)  и използва най-леката джаджна библиотека от стотиците за този език.

Когато излезе 0,1 въпреки, че обра овации, бях решил да не го слагам. Нямаше някакви неща, които ми трябват. Но освен това, като му огледах зависимостите, бяха прекалено нови. Не знам защо на версия 0,2 се излъгах. Не мога да си го обясня. В резултат така си порутих системата, както е ставало само в дните, когато бях на лошото момче от квартала. Бях забравил, какво е да имаш нестабилна и неработеща система.

Повечето зависимости се намират в актуалното издание. Но не всички. Например FLTK му е стара дори от Сид. Хубавото е, че е почти безпроблемна да се надгради от извори. Незнайно защо обаче, тя ползва Кайро. Точно проклетото Кайро. Като иска да рисува върху платно, то да вземе Gegl или дори Ежас, защо по дяволите Кайро?!? А то бара на ниво X11, което означава, че всички духат. Всъщност само ГТК не се чупи. От тук ми дойде половината порутване, но не се отказах.

Останалите зависимости си стават от стабилната версия, но пак има изключения. Например gcc трябва да е от Джеси. Решаваме, че Джеси е достатъчно стабилна. Е да, ама не знам кой малоумник е решил, че glib (и още някакви) трябва да е зависимост на gcc и от там разтресохме и приложенията с GTK. Glib не е като glibc и няма обратна съвместимост. В момента нищо при мен не работи както трябва, ако изобщо нещо работи.

Има някакви библиотечки, които не присъстват в Дебиан, но понеже са малки и нищо друго не ги ползва, те не чупят системата. И тогава стигнах до webkit. Е той ми разказа играта. Незнайно защо му е необходим Питон. Питон е още нещо, което е несъвместимо с предишните си версии. При мен беше изостанал на 2,5, тук се държеше на 2,7,нещо. Пак, че не е 3,0. Надстройване на Питон не е елементарна задача. Въпреки, че му даваш нови неща, той настоява да ползва по-стари (тук вината може би е на пакетажният цех) и да махнеш старите, новият Питон продължава да се държи нещо средно между старата и новата версия. Някой проблеми успях да ги запуша. Но така и не успях да оправя докладван проблем:

https://github.com/clbr/webkitfltk/issues/1

За пича проблем нямало. Е за мен има, а явно и повдигналият билета също. И тук вече му теглих една майна.

Сега се чудя, колко дни ще ми трябват да си поправя системата. Ако питаш защо са ми трябвали дни, за нещо правещо се за няколко часа, отговорът е прост. Прекарах времето основно в чакане. Например около 3 МБ ги тегля за час. А ръчно си тегля пакетите, а не през пакетната система, за да не доунищожа основната система, в резултат, на което сега и пакетната система трябва да поправям. Изобщо лудница. Интересно, че като качих gcc от 3,(не помня какво) до 4,7,1 нямах проблеми. Но от 4,7 на 4,8,3 не стана така. Това ме учуди.

Та така, забавляваме си се.


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: ddantgwyn в Feb 05, 2015, 12:38
В българската теория няма понятия компилиране и интерпретиране. Те се предават под общият термин транслиране. Защо са решили така, нямам нито най-малка идея.

Всъщност има, но нека не навлизаме в подробности :)


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: bvbfan в Feb 05, 2015, 13:10
Кво напрайхте  ??? Ползвай въпросната библиотека, но не я слагай в системните пътища да не ти чупи останалите програми. LD_PRELOAD http://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: go_fire в Feb 05, 2015, 13:49
Благодаря за насочването bvbfan!

Ddantgwyn напротив, навлез! Винаги е добре да се научи нещо.


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: remotexx в Feb 05, 2015, 21:18
Предполагах че нещо такова ще стане.. но да се върнем по темата

Понеже съм ти длъжник ($2) ето и моето мнение:

1. Обади им се да си поправят и зависмостите защото това Кайро се не види там
http://fifth-browser.sourceforge.net/downloads.html

2. Следващия път ползвай виртуалка за тестове

3. и 4. Някой меко казано странни наблюдения:
- Хем се оплакват от това че Опера вече е само обвивка на Кромиума хем те пък си правят обвивка на УебКит
- Имам усещането че са заложили на грешния кон - защо УебКит 1 като вече има УебКит 2 и скоро 1-то ще замине в небитието т.е. в смисъл като не ти поддържа новостите...
- Като искаш малък браузър и/ли бърз избери си някой от тези по-малките тука
http://fifth-browser.sourceforge.net/propaganda.html
Мидори, Аврора и пр. пък ако искаш не само обвивка ами баш браузър - те нещо като конзолен ама с GUI обвивка аз много си тача тоя вградения... НетСърф
http://www.netsurf-browser.org/
+ собствен енджин
+ Written in C (даже не и С++)
ама интересно що с него не се мерят - щото то най - лесно обвивка за готов енджин да се пише нали

П.П. Аз навремето съм им ползвал само HTML парсера (Hubbub ($2)) за да не се мъча с регулярни изрази - мамицата им и новите браузъри никой вече не ти дава (HTML) parser tree  най-близкото което можеш да докопаш е Render Tree ами ако не щеш да рендваш си е чисто самоубийство ...та така го ползвах като С/С++ заместител на Html Agility Pack ($2)


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: go_fire в Feb 05, 2015, 23:12
Оле-ле, бях забравил за ЛЖ. Преместих се там, след като леля Гошовица взе да прави мизерии (те ги наричат иновации). Не ми хареса и едва след няколко публикации спрях. Май сам ще трябва да си пиша платформа :(

Кайро е зависимост на FLTK, не на петдесетият. Оказа се, че дори кайрото в лошото момче не е достатъчно ново. Но да имат неописани зависимости, но са все малки и вероятно присъстват в дистрото.

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

Ако бяха освободили вече ненужното Престо, съм сигурен, че биха го ползвали ;) Ползват, каквото има, а има само два развити двигателя. Те не се ядосват толкова, че Опера е вече Хром, а че вече не е Опера, нещото, което вбесява всичките оперджии. И точно това се опитват да постигнат и няма да успеят, защото нямат Престо и старият код :( Но все пак е обещаващ.


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: remotexx в Feb 06, 2015, 01:02
ами тогава това
http://otter-browser.org/


Титла: Re: Транслиране по подразбиране на Ц/Ц++ в гцц
Публикувано от: go_fire в Feb 06, 2015, 08:54
Да този още не съм го разглеждал, И той ми седи в чакащият „списък“ от отдавна, но лаптопа ми е прекалено слаб за него, а с настолната машина имам определени проблеми и затова още чака :(

п.п. Преди месец или повече минах на Емакс 24,4. Горе-долу причината беше основно eww. За първи път имат нещо свое. Досега са имали върху w3m, linx (или ks не помня) и webkit (през Питон, проект на онези фамозни китайци). Не се впечатлих никак. Links2 е степени отгоре. Но пък е доста впечатляващо за нещо, което е едва стотинa реда.