Изпечатай

[go_fire]

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

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

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

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

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

[gat3way]

Това зависи от makefile-овете, но по принцип може да пробваш да ги нашиеш в CFLAGS и/или съответно за линкера в LDFLAGS променливите. Разбира се ако makefile-а е написан грубиански, няма файда от това упражнение.

[go_fire]

Извинявам се, за още по-глупавият въпрос, но в кой файл се настройват CFLAGS и LDFLAGS?

[gat3way]

Това са environment променливи, ако искаш си ги експортвай в .bash_profile или там каквото ти е на шела.

[Naka]

това са шелски променливи.
аз правя така:

Код:

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 

[go_fire]

Много благодаря и на двамата!

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

[gat3way]

Едното се изпълнява за шелове с контролен терминал, другото - обратното. bashrc примерно би трябвало изпълни за cronjob който е шел скрипт. bash_profile ще се изпълни когато се логнеш през ssh да речем. Обаче нещата са размити и обикновено едното е направено така че да изпълнява другото. И за мен понякога е объркващо ако трябва да съм честен

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

target:
      cc source.c -o executable

вместо:

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


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

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

[go_fire]

Ще ползвам моя стара тема, за да попитам, така и така съм забравил да я отбележа като решена. Става въпрос за статично свързване. Как се прави това?

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

[gat3way]

За да я линкнеш статично, ще ти трябват статичните библиотеки, а не .so-тата, нещо което с известна вероятност нямаш. При положение че са налични, в реда с опциите на линкера слагаш -Bstatic преди -lбиблиотека1 -lбиблиотека2 ...

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

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

[go_fire]

Аха, това е добре. Но доколкото разбирам първо трябва да транслирам въпросната библиотека като „статична“, защото казваш, че shared objects не стават. А това как се прави?!

[gat3way]

Не знам какво имаш предвид това "транслиране".

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

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

[go_fire]

В българската теория няма понятия компилиране и интерпретиране. Те се предават под общият термин транслиране. Защо са решили така, нямам нито най-малка идея.

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

[gat3way]

gcc -o hello.c няма да създаде библиотека.

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

[go_fire]

Понеже съм леко тъп да попитам. Защо да е лошо или нелогично? Например, ако ffmpeg може да се държи като изпълним, защо да си свалям mplayer? Вярно mplayer може да ми прави екранни снимки, може да закача надписи, има статистики, може да рисува върху екрана (например информация или контролни копчета, т.нар. OSD) и още някакви начини. Но, ако просто искам да гледам нещо, защо не?

[gat3way]

Че с ffmpeg не идваха ли разни tool-ове, ето ти изпълними файлове значи.

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

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

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

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

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