Комментарии 32
Во кто-нибудь может объяснить, почему все так в линуксе? Ну не хватает программе возможностей системной библиотеки - положи Альтернативу рядом с ней и используй. Или только хард код-путь? Только из системой папки... Снап вроде бы попытался, но не смог. В Windows проблема более-менее решена, а тут прям 90-е полным ходом
снап - самая отвратительная штука что есть в убунте. Кладут каждую программу в образ по 300-500мб, всё тормозит, работает отвратительно.
+снап никто кроме canonnical не продвигает.
Если уж хочется запакетитироваться - Flatpack тогда.
p.s. про windows в 2024ом году сказать не могу, но в 2010ом году в windows решение было так себе. Постоянно приходится ставить "Visual C++ Redistributable for Visual Studio" или netframework, да ещё по 3-5 версий сразу. Исправили сейчас или всё ещё также ставятся?
Да в общем-то уже лет 10 как поправили.
Точнее так - в 2015 в десятке уже точно всё было круто, а вот в 8.1 вроде бы таких проблем небыло и оно всё само, но память может подводить.
Но в целом я понимаю о чём вы. Семёрка была ужасна и восьмёрка сделала по ряду фронтов скачок вперёд, а уж десятка вообще сделала винду конфеткой. Хотя тоже не везде - powershell, относительно линуксов, всё ещё ужасен.
Всё так же, только версий .Net и С++ Redistributable стало гораздо больше :)
Но при всём при том никто не говорит "ой, тут в системной библиотеке нет нужной нам функции, поэтому у нас лапки"
Версия VCredist с 2015 года одна - последняя.
Неткоры - да, каждый отдельн
У меня другая информация насчет VC++:
Если бы вы кликнули по ссылке download и запустили скачанное, то увидели бы именно то, что я и написал. Но вы этого не сделали.
И даже не погуглили, т.к. первая ссылка это
Не вижу смысла спорить, но точно существует несколько версий файла (возможно с одинаковой начинкой - это не проверял):
Мicrosoft Visual C++ 2015 Redistributable (x64) - 14.0.23026
Microsoft Visual C++ 2017 Redistributable (x64) - 14.16.27033
Microsoft Visual C++ 2015-2022 Redistributable (x64) - 14.40.33810
А толку, если весь этот балаган тащат и устанавливают приложения, и плевать им на результаты гугла и написанное на сайте M$?
Соглашусь про снап - но это была попытка, хотя и не очень удачная, решить эту и другие проблемы
Кладут каждую программу в образ по 300-500мб,
у flatpak иногда схожие проблемы из-за "изоляции".
Как раз в линуксе существует LD_PRELOAD. Ну или я не понял о чем вы.
Ну не хватает программе возможностей системной библиотеки - положи Альтернативу рядом с ней и используй.
Так ни кто так делать и не мешает. У меня три программы в /opt стоит. С полным набором библиотек. И это не считая игр в ~/Games, в которой некоторые библиотеки еще со времен Lenny.
тут речь не про рядовые зависимости типа boost, а что то в духе libatomic, pthread и с ними ещё можно относительно просто разобраться, а вот чтоб изолироваться от glibc это нужно столько приседаний сделать что одуреть можно, а в большинстве кодовых баз эти приседания в принципе не возможны (если интересны детали есть отличный доклад про это https://youtu.be/Z7WuUhPJ-cU)
В win чтоб запускать прогу собраную самым последним тулчейном vc на win7 достаточно просто поставить последний пакет Redistributable C++, а под linux чтоб мне запустить хоть что то собранное последним gcc на условной ubuntu 12.04 в общем случае вообще ни чего не сделать это практически нереально без полного обновления ОС включая ядро. найс портируемость linux.
то собранное последним gcc на условной ubuntu 12.04
в общем случае вообще ни чего не сделать это практически нереально без полного обновления ОС
Можно взять сборку "последнего gcc" такую, чтобы он линковал не с glibc, а с musl. И тогда собранный на "ubuntu 12.04" код там же и запустить можно. И тогда можно будет вообще musl статически слинковать и никакие библиотеки не таскать с собой.
за давностью разбирательства с этой проблемой не могу говорить с уверенностью, но для того чтоб линковаться с musl нужно подменять загрузчик и при наличии "закрытых" зависимостей собранных с glibc это может взорвать приложение.
Чтобы линковаться с MUSL ничего подменять не нужно. Это стандартный способ сборки статических бинарников в том же Rust.
что же тогда в документации другое сказано? https://wiki.musl-libc.org/faq#Q:-Where-is-<code>ldd</code>
Технически - можно и способов существует много (можно вообще хоть все кроме glibc статически линковать). Просто принято использовать системное а не разводить свалку.
Либо я не понял сути проблемы, либо тут незнание матчасти. Поэтому я тут набросал пример, и зову
к коллайдеру !
Пример до убогости прост. Не по стандарту, gcc хавает.. но не суть
// helloworld.cpp
#include "helloworld.hpp"
#include <iostream>
void helloWorld() {
std::cout << "Hello, world!" << std::endl;
}// helloworld.hpp
#ifndef LIBHELLOWORLD_H_INCLUDED
#define LIBHELLOWORLD_H_INCLUDED
void helloWorld();
#endif /* LIBHELLOWORLD_H_INCLUDED */// main.cpp
#include <iostream>
#include "helloworld/helloworld.hpp"
int main ( void )
{
helloWorld();
return 0;
}hello_world_cpp/helloworld$ g++ -c -fPIC -o bin/helloworld.o helloworld.cpp
hello_world_cpp/helloworld$ gcc -shared -o bin/libhelloworld.so bin/helloworld.o
hello_world_cpp$ g++ -v -Wall -o main main.cpp -L. -I. -Lhelloworld/bin/ -lhelloworld.
├── helloworld
│ ├── bin
│ │ ├── helloworld.o
│ │ └── libhelloworld.so
│ ├── helloworld.cpp
│ └── helloworld.hpp
├── main
└── main.cpp
внимание на libhelloworld.so => not found
/hello_world_cpp$ ldd main
linux-vdso.so.1 (0x00007ffe53fa6000)
libhelloworld.so => not found
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007662a1000000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007662a0c00000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007662a0f17000)
/lib64/ld-linux-x86-64.so.2 (0x00007662a1365000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007662a1313000)
/hello_world_cpp$ sudo cp helloworld/bin/libhelloworld.so /usr/lib/x86_64-linux-gnu/libhelloworld.solibhelloworld.so => /lib/x86_64-linux-gnu/libhelloworld.so
hello_world_cpp$ ldd main
linux-vdso.so.1 (0x00007ffe20838000)
libhelloworld.so => /lib/x86_64-linux-gnu/libhelloworld.so (0x000073ea2c4d2000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x000073ea2c200000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000073ea2be00000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000073ea2c117000)
/lib64/ld-linux-x86-64.so.2 (0x000073ea2c4fc000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000073ea2c4a5000)
hello_world_cpp$ export LD_LIBRARY_PATH=helloworld/bin/:$LD_LIBRARY_PATH
hello_world_cpp$ ./main
Hello, world!Тада!! libhelloworld.so => helloworld/bin/libhelloworld.so
hello_world_cpp$ ldd main
linux-vdso.so.1 (0x00007ffd9fdb9000)
libhelloworld.so => helloworld/bin/libhelloworld.so (0x00007f4741431000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4741000000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4740c00000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f474132a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f474143d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f47412fd000)
Пересобираем динамическую библиотеку
#include "helloworld.hpp"
#include <iostream>
void helloWorld() {
std::cout << "Hello, Habr!" << std::endl;
}hello_world_cpp/helloworld$ g++ -c -fPIC -o bin/helloworld.o helloworld.cpp
hello_world_cpp/helloworld$ gcc -shared -o bin/libhelloworld.so bin/helloworld.o
hello_world_cpp$ ./main
Hello, Habr!Не знаю зачем мне это понадобилось.. во имя LD_LIBRARY_PATH конечно
Это говорит о том, что есть значительная доля браузерного трафика, который может задействовать HTTP/3, но пока этого не делает. К сожалению, найти этому объяснение возможности у меня нет.
А разве из России на не-российские сайты QUIC в принципе работает?(спасибо в частности РКН)
А допустим из Китая и прочих Таджикистанов?
А во всяких Европах на мобильных сетях где DPI?
Это же перевод, какое им дело до РФ и прочих Таджикистанов? :)
А Китай просто свой GFW скорее всего обновит новые паттерны искать и всё.
Как обстоят дела с HTTP/3 в сURL на середину 2024 года