Size: a a a

2021 March 31

DH

Dark Hole in dlang.ru
Oleg B
а где я сделал иначе?
Я запутался просто, вот и уточнил
источник

OB

Oleg B in dlang.ru
Dark Hole
Пакеты не представляют из себя конечный продукт значит по идее abi не имеют
допустим
источник

OB

Oleg B in dlang.ru
Dark Hole
Пакеты не представляют из себя конечный продукт значит по идее abi не имеют
предполагается, что so — результат сборки пакета, пакет может содержать зависимости, которые линкуются к выходному файлу статически, значит их символы попадают в so, следовательно из-за префиксов меняется содержимое so
источник

EP

Egor Pugin in dlang.ru
Oleg B
предполагается, что so — результат сборки пакета, пакет может содержать зависимости, которые линкуются к выходному файлу статически, значит их символы попадают в so, следовательно из-за префиксов меняется содержимое so
чужие влинкованные не должны быть видны
источник

OB

Oleg B in dlang.ru
Egor Pugin
чужие влинкованные не должны быть видны
т.е. их в любом случае оборачивать?
источник

EP

Egor Pugin in dlang.ru
они видимость должны скрытую иметь
источник

EP

Egor Pugin in dlang.ru
т.е. из сошки будут торчать только символы этого пакета, но не зависимых
источник

OB

Oleg B in dlang.ru
Egor Pugin
т.е. из сошки будут торчать только символы этого пакета, но не зависимых
а если это (результат сборки пакета) не динамическая, а статическая библиотека?
источник

EP

Egor Pugin in dlang.ru
ну тогда какую проблему рассматриваем?
источник

DH

Dark Hole in dlang.ru
Oleg B
допустим
Таким образом все внешние ABI будет прописываться на уровне самого приложения/библиотеки, а не в зависимостях. Таким образом можно забить на версионирование в extern(C/C++).

Конфликт может возникнуть если ты линкуешь не D код к D коду статически.
источник

EP

Egor Pugin in dlang.ru
Oleg B
а если это (результат сборки пакета) не динамическая, а статическая библиотека?
нужно новую проблему обозначить
источник

OB

Oleg B in dlang.ru
Egor Pugin
нужно новую проблему обозначить
проблема прежняя: изменение списка имён символов
источник

OB

Oleg B in dlang.ru
Oleg B
проблема прежняя: изменение списка имён символов
возможно надуманная
источник

DH

Dark Hole in dlang.ru
Dark Hole
Таким образом все внешние ABI будет прописываться на уровне самого приложения/библиотеки, а не в зависимостях. Таким образом можно забить на версионирование в extern(C/C++).

Конфликт может возникнуть если ты линкуешь не D код к D коду статически.
Я что-то не так понял?
источник

EP

Egor Pugin in dlang.ru
Oleg B
проблема прежняя: изменение списка имён символов
так они на стадии компиляции получили префиксы
источник

OB

Oleg B in dlang.ru
Egor Pugin
так они на стадии компиляции получили префиксы
окей, но всё равно пока не складывается картина как это должно работать

допустим я хочу собрать некоторый код
void foo()
{
 func1();
 func2();
}

и вот эти func1 и func2 определены в разных зависимостях, при компиляции как он поймёт какой префикс какой функции ставить чтобы линковать с уже собранными файлами с префиксами?
источник

OB

Oleg B in dlang.ru
т.е. это ещё и анализ исходников должен быть?
источник

OB

Oleg B in dlang.ru
собрать то можно это в .a по отдельности всё (инкрементно типа)
источник

DH

Dark Hole in dlang.ru
Oleg B
окей, но всё равно пока не складывается картина как это должно работать

допустим я хочу собрать некоторый код
void foo()
{
 func1();
 func2();
}

и вот эти func1 и func2 определены в разных зависимостях, при компиляции как он поймёт какой префикс какой функции ставить чтобы линковать с уже собранными файлами с префиксами?
Тебе придётся прописать import сначала.
источник

EP

Egor Pugin in dlang.ru
ну он по инклюду понимает, что вот этот путь из -ipackage mylib1-0.0.1, а другой путь из -ipackage mylib2-1.2.3.
источник