I
Проблема такова, у меня не работает приложение, по сбору данных чужих компьютеров
Что можете порекомендовать?
При запуске говорит, что нет dll
Size: a a a
2021 March 29
НП
AT
Проблема такова, у меня не работает приложение, по сбору данных чужих компьютеров
Что можете порекомендовать?
При запуске говорит, что нет dll
Что можете порекомендовать?
При запуске говорит, что нет dll
обратиться за советом в Управление К
НП
От них помощи никак не дождусь
IZ
Проблема такова, у меня не работает приложение, по сбору данных чужих компьютеров
Что можете порекомендовать?
При запуске говорит, что нет dll
Что можете порекомендовать?
При запуске говорит, что нет dll
Посоветуем изучать язык с/с++, тут @supapro
I
A ß
посмотри в config.log какой CC используется
еще одна ситуация. сборка встала но эти флаги он не устанавливает автоматом, из-за чего под другую архитектуру компилится библиотека(80386). Если прописать вручную используемый компилятор CXX="arm-linux-g++", то компилятор ругается на заголовки:
Как прописать откуда включать эти библиотеки? И можно ли это вообще?
в help нашел только префикс для директории установки
In file included from /usr/include/fcntl.h:34:0,
from ../include/common.h:31,
from common.c:20:
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:33:5: error: unknown type name '__off_t'
__off_t l_start; /* Offset where the lock begins. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:34:5: error: unknown type name '__off_t'
__off_t l_len; /* Size of the locked area; zero means until EOF. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:39:5: error: unknown type name '__pid_t'
__pid_t l_pid; /* Process holding the lock. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:47:5: error: unknown type name '__off64_t'
__off64_t l_start; /* Offset where the lock begins. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:48:5: error: unknown type name '__off64_t'
__off64_t l_len; /* Size of the locked area; zero means until EOF. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:49:5: error: unknown type name '__pid_t'
__pid_t l_pid; /* Process holding the lock. */
^
Как прописать откуда включать эти библиотеки? И можно ли это вообще?
в help нашел только префикс для директории установки
YS
еще одна ситуация. сборка встала но эти флаги он не устанавливает автоматом, из-за чего под другую архитектуру компилится библиотека(80386). Если прописать вручную используемый компилятор CXX="arm-linux-g++", то компилятор ругается на заголовки:
Как прописать откуда включать эти библиотеки? И можно ли это вообще?
в help нашел только префикс для директории установки
In file included from /usr/include/fcntl.h:34:0,
from ../include/common.h:31,
from common.c:20:
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:33:5: error: unknown type name '__off_t'
__off_t l_start; /* Offset where the lock begins. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:34:5: error: unknown type name '__off_t'
__off_t l_len; /* Size of the locked area; zero means until EOF. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:39:5: error: unknown type name '__pid_t'
__pid_t l_pid; /* Process holding the lock. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:47:5: error: unknown type name '__off64_t'
__off64_t l_start; /* Offset where the lock begins. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:48:5: error: unknown type name '__off64_t'
__off64_t l_len; /* Size of the locked area; zero means until EOF. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:49:5: error: unknown type name '__pid_t'
__pid_t l_pid; /* Process holding the lock. */
^
Как прописать откуда включать эти библиотеки? И можно ли это вообще?
в help нашел только префикс для директории установки
судя по ошибке, у тебя компилятор взял инклуды из хоста, и ожидаемо все сломалось
AP
Всем привет. В asio есть возможность формирования последовательности буферов для приёма/отправки данных через сокет с гарантией отсутствия как минимум лишних копирований. Кто-нибудь в курсе, как это реализовано? Учитывая, что syscall send ожидает непрерывный кусок памяти
Будьте аккруатнее - контейнер, который вы передаёте на вход может быть скопирован. Так что передавайте на вход спаны или другие легковесные вьюшки, внимательно читайте документацию
C
нет, не подскажу. Правильно надо читать документацию по твоему компилятору и "прописывать компановку".
Возможно, оно вообще не умеет линковать эти .dll статически
Возможно, оно вообще не умеет линковать эти .dll статически
Разве есть линкеры, умеющие линковать dll статически?
Aß
еще одна ситуация. сборка встала но эти флаги он не устанавливает автоматом, из-за чего под другую архитектуру компилится библиотека(80386). Если прописать вручную используемый компилятор CXX="arm-linux-g++", то компилятор ругается на заголовки:
Как прописать откуда включать эти библиотеки? И можно ли это вообще?
в help нашел только префикс для директории установки
In file included from /usr/include/fcntl.h:34:0,
from ../include/common.h:31,
from common.c:20:
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:33:5: error: unknown type name '__off_t'
__off_t l_start; /* Offset where the lock begins. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:34:5: error: unknown type name '__off_t'
__off_t l_len; /* Size of the locked area; zero means until EOF. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:39:5: error: unknown type name '__pid_t'
__pid_t l_pid; /* Process holding the lock. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:47:5: error: unknown type name '__off64_t'
__off64_t l_start; /* Offset where the lock begins. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:48:5: error: unknown type name '__off64_t'
__off64_t l_len; /* Size of the locked area; zero means until EOF. */
^
/usr/include/arm-linux-gnueabihf/bits/fcntl.h:49:5: error: unknown type name '__pid_t'
__pid_t l_pid; /* Process holding the lock. */
^
Как прописать откуда включать эти библиотеки? И можно ли это вообще?
в help нашел только префикс для директории установки
это открытый проект какой-то?
IZ
Разве есть линкеры, умеющие линковать dll статически?
Нет, но может у него есть два варианта этой библиотеки
JT
Будьте аккруатнее - контейнер, который вы передаёте на вход может быть скопирован. Так что передавайте на вход спаны или другие легковесные вьюшки, внимательно читайте документацию
Спасибо!
Вообще я знаком более-менее с ней на пользовательском уровне. Просто стало интересно, мол, как же так, есть гарантия отсутствия оверхеда по производительности, а сокет принимает только по сути спан на сырую память. Мне не хватало пинка в сторону writev и sendmsg)) Как-то стыдно даже, что не знал о таких вызовах
А так классная библиотека в сочетании со spawn-ом
Вообще я знаком более-менее с ней на пользовательском уровне. Просто стало интересно, мол, как же так, есть гарантия отсутствия оверхеда по производительности, а сокет принимает только по сути спан на сырую память. Мне не хватало пинка в сторону writev и sendmsg)) Как-то стыдно даже, что не знал о таких вызовах
А так классная библиотека в сочетании со spawn-ом
JT
sendmsg скорее всего.Вы правы. В случае с UDP действительно скорее всего будет вызов sendmsg
DS
Будьте аккруатнее - контейнер, который вы передаёте на вход может быть скопирован. Так что передавайте на вход спаны или другие легковесные вьюшки, внимательно читайте документацию
Вроде как const buffer sequence это адаптеры только, в каком случае оно копируется? Ещё в beast видел использование этих buffer sequence прям вообще в крайнем варианте, когда оно чуть не из символов собирается. А это ж тоже мне кажется антипаттерн, это дорого даже в случае iovec, краем глаза даже замечал там отдельные buf-stream схлопыватели потому что с ssl это ну прям совсем плохо.
AP
Вроде как const buffer sequence это адаптеры только, в каком случае оно копируется? Ещё в beast видел использование этих buffer sequence прям вообще в крайнем варианте, когда оно чуть не из символов собирается. А это ж тоже мне кажется антипаттерн, это дорого даже в случае iovec, краем глаза даже замечал там отдельные buf-stream схлопыватели потому что с ssl это ну прям совсем плохо.
Вот например https://www.boost.org/doc/libs/1_75_0/doc/html/boost_asio/reference/basic_stream_socket/async_receive/overload1.html
"Although the buffers object may be copied as necessary"
Если buffers окажется вектором из буферов, то скопируется вектор (да, с динамической аллокацией)
"Although the buffers object may be copied as necessary"
Если buffers окажется вектором из буферов, то скопируется вектор (да, с динамической аллокацией)
DS
Вот например https://www.boost.org/doc/libs/1_75_0/doc/html/boost_asio/reference/basic_stream_socket/async_receive/overload1.html
"Although the buffers object may be copied as necessary"
Если buffers окажется вектором из буферов, то скопируется вектор (да, с динамической аллокацией)
"Although the buffers object may be copied as necessary"
Если buffers окажется вектором из буферов, то скопируется вектор (да, с динамической аллокацией)
А вектор из буферов подходит под mutable buffer sequence без адаптеров?
2021 March 30
AP
А вектор из буферов подходит под mutable buffer sequence без адаптеров?
Да. Пара разрабов на этом обжигались
CD
Ну формально требование копироваться разрушаться и итерироваться, должно проходить
DS
Ну там да, всё заточено на то что адаптеры строят view, а уж как буфер хранить сам думай.