On Sunday, November 19, 2017 at 2:02:54 PM UTC+1, fir wrote:
> ja odwrotnie, kompilowanie ststyczne to dla mnie za duzo roboty

Wszystko zależy od okoliczności. Jeśli aplikacja korzysta z kilku
nie za dużych bibliotek 'poza systemowych', a poza tym z systemu, to
skompilowanie statyczne faktycznie wszystko upraszcza - jeden
plik copy-paste i działa. Gorzej, gdy trzeba zlinkować pól giga -
nie wiem czy to w ogóle jest możliwe w rozsądnym czasie.


> bo o ile pamietam (nie jestem pewien czy dobrze pamietam ale chyba tak) aby
> statyczny linker dzialal 'wybiórczo'

Kiedyś czytałem że to jest w ogóle niemożliwe w przypadku języków c/c++.
Uzasadnienia autor nie podawał - ja uwierzyłem.


> nie wystarczy zlinkowac duzego pojedynczego pliku.o (powiedzmy 5 MB) - jesli
uzywamy tylko jednej prostej funkcji z tego obiektu i tak statyczny linker zlinkuje 5
MB -
> aby dzialal wybiórczo tworca tej
> liby musialby kompilowac ja do wielu skladowych .o i potem pakowac ja w jedną
zbiorczą libe .lib
Tak, twórca musiałby dostosować liba do linkowania statycznego, ale to i
tak na nic, jeśli jedna funkcja wywołuje drugą, itd.


> (tak mi sie przynajmniej wydaje bo co ciekawe nigdy o tym wiecej nie czytalem i
nigdy jakos specjalnie tego nie uzywalem itd) tak ze to jest ok (dodatkowo np pozwala
kompilowac rozne podkawalki z roznymi opcjami kompilacji) ale wymaga zauwazalnej
ilosci dodatkowej roboty a dla mnie dodatkowa robota jest zwykle denerwujaca (ta
robota moglaby byc
> byc moze mniejsza gdyby toole robily troche wiecej z automatu

Pracowałem na kilku bibliotekach w visual studio i wszystko działo się z
automatu, tylko wybierałem czy statycznie czy dynamicznie.


> itp, tak naprawde mozna tez zauwazyc ze dynamiczne linkowanie
> tez mogloby byc zrobione tak by dzialac wybiórczo acz to by co nieco skomplikowalo
sprawy)

Musiałby być kod źródłowy i podpowiedzi kompilatora który element kodu
zależy od którego, bo po samym call nie wiem czy kompilator w ogóle
może wywnioskować.


> dla mnie linkowanie dllek jest ok
> tyle ze nalezy moze jedynie pamietac by te dllki mialy rozsądne
> rozmiary (rozsądna jak na dzis to dla mnie chyba do 10 MB na jedną)
> oraz by dependencje miedzy nimi byly jak najmniejsze (tj by nie bylo ich duzo i jak
juz sa by mialy w swoim secie jak najmniej dependencji (te dependencje miedzy dllkami
mozna zliczajac zliczajac kreseczki importow na grafie miedzy dllkami, (mowie o
importach calej dllki nie pszczegolnych symboli)
> np jak ktos mialby 10 dllek z ktorych kazda importowalaby kazda inną to w sumie
zdaje sie tych dependencji byloby 90 - za duzo,

A co ze statycznymi zmiennymi? Jeśli lib ma działać 'od zera' to przynajmniej
jego dane trzeba zaimportować. By trzeba dane statyczne podmieniać przed
wywoływaniem metody z innego dll... nie wiem jak to jest w praktyce, ale
coś mi się wydaje, że po protu ładuje się liby jak są potrzebne i nie
ma że za dużo.


> u mnie w moich projektach mam na
> przyklad zaleznosc/import do green.fire.dll ktora z kolei ma importy do 7
systemowych dllek (kernel32.dll gdi32.dll msvcrt.dll psapi.dll user32.dll winmm.dll
ws2_32.dll) sam exe moze tez siegac do niektorych bezposrednio (akurat moj klient
irca siega bezposrednio do kernel32 (i do msvcrt.dll choc to jest zrozumiela) na 12
funkcji (dotyczacych critcal section, tls, exit process, get masage adress itp, i
tego ciagle do konca troche nie lapie szczerze mowiac, czy to gcc wkompilowuje te 12
funkci jako normalne calle w startupie mojego kodu czy tez moze tworzy sobie takie
importy tak troszke jakby na wyrost?) (wiem przynajmniej jedno, jak sam zasembluje
sobie swoim asemblerem swoj plik exe to moge miec eleganckie zero importow mimo ze
program dziala (i pisze na konsole przez msvcrt.printf - hmm - w takim razie to tez
jest dziwne, moze moj exe oszukuje plugin do total commandera bo importy dzialają ale
sie nie pokazują)

Nie rozumiem, to już jakieś Twoje bardzo specyficzne (co nie znaczy że
złe) rozwiązanie.

Pozdrawiam