Сообщение Re[2]: [UPD]Re: gcc.exe и путь длиной в 260 символов от 08.09.2021 17:35
Изменено 08.09.2021 17:38 ononim
Re[2]: [UPD]Re: gcc.exe и путь длиной в 260 символов
O>>Почему ты думаешь оно искусственное,
O>>UPD А нет, если не прокатит — по ссылке выше есть еще параграф 'Enable Long Paths in Windows 10, Version 1607, and Later'
BFE>Потому что длинные пути у меня включены и с ними нет никаких проблем.
BFE>Как это поможет gcc? Никак не поможет.
Там еще манифестик надо вставить в ресурсы ехе-шника.
O>>MAX_PATH в винде равен 260,
BFE>Почему MS не переопределить MAX_PATH в 65535 — это отдельный вопрос.
Хотябы потому что он зашит в WIN32_FIND_DATA и скорее всего еще в куче менее известных структур.
O>>чтобы это ограничение обойти, программа должна во-первых использовать wide-версии системных АПИ,
O>>а во-вторых делать путь с префиксом \\?\.
BFE>Это должно делаться автоматически: если префикс отсутствует, то добавляем втихую и работаем.
BFE>Да. Вот я и спрашиваю: есть такая сборка gcc, которая это умеет?
Опенсорс же — сделай если надо. Но скорее всего дело не в самом гцц, а каком нить mingw с которым он сам собран, а сам gcc пользует посиксовый open().
O>>а если нет — НЕФИГ ДЕЛАТЬ ТАКИЕ ПУТИ
BFE>У меня в проекте вложенность каких-то 10 уровней => на длину каталога остаётся каких-то 26 символов. Как при этом работать, если только каталог для .o файлов называется debug-build-gcc-arm-10.3-2021.07-mingw-w64-i686-arm-none-linux-gnueabihf ?
Кхе, вот сделай base64(md5(этой строки)) и будет норм, и информативности не убудет, ведь явно ты тут ниче не читаешь
O>>UPD А нет, если не прокатит — по ссылке выше есть еще параграф 'Enable Long Paths in Windows 10, Version 1607, and Later'
BFE>Потому что длинные пути у меня включены и с ними нет никаких проблем.
BFE>Как это поможет gcc? Никак не поможет.
Там еще манифестик надо вставить в ресурсы ехе-шника.
O>>MAX_PATH в винде равен 260,
BFE>Почему MS не переопределить MAX_PATH в 65535 — это отдельный вопрос.
Хотябы потому что он зашит в WIN32_FIND_DATA и скорее всего еще в куче менее известных структур.
O>>чтобы это ограничение обойти, программа должна во-первых использовать wide-версии системных АПИ,
O>>а во-вторых делать путь с префиксом \\?\.
BFE>Это должно делаться автоматически: если префикс отсутствует, то добавляем втихую и работаем.
BFE>Да. Вот я и спрашиваю: есть такая сборка gcc, которая это умеет?
Опенсорс же — сделай если надо. Но скорее всего дело не в самом гцц, а каком нить mingw с которым он сам собран, а сам gcc пользует посиксовый open().
O>>а если нет — НЕФИГ ДЕЛАТЬ ТАКИЕ ПУТИ
BFE>У меня в проекте вложенность каких-то 10 уровней => на длину каталога остаётся каких-то 26 символов. Как при этом работать, если только каталог для .o файлов называется debug-build-gcc-arm-10.3-2021.07-mingw-w64-i686-arm-none-linux-gnueabihf ?
Кхе, вот сделай base64(md5(этой строки)) и будет норм, и информативности не убудет, ведь явно ты тут ниче не читаешь
Re[2]: [UPD]Re: gcc.exe и путь длиной в 260 символов
O>>Почему ты думаешь оно искусственное,
O>>UPD А нет, если не прокатит — по ссылке выше есть еще параграф 'Enable Long Paths in Windows 10, Version 1607, and Later'
BFE>Потому что длинные пути у меня включены и с ними нет никаких проблем.
BFE>Как это поможет gcc? Никак не поможет.
Там еще манифестик надо вставить в ресурсы ехе-шника.
В манифестике еще стоит попробовать включить поддержку UTF8 для -A функций, глядишь это еще и длинные пути включит — https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
O>>MAX_PATH в винде равен 260,
BFE>Почему MS не переопределить MAX_PATH в 65535 — это отдельный вопрос.
Хотябы потому что он зашит в WIN32_FIND_DATA и скорее всего еще в куче менее известных структур.
O>>чтобы это ограничение обойти, программа должна во-первых использовать wide-версии системных АПИ,
O>>а во-вторых делать путь с префиксом \\?\.
BFE>Это должно делаться автоматически: если префикс отсутствует, то добавляем втихую и работаем.
BFE>Да. Вот я и спрашиваю: есть такая сборка gcc, которая это умеет?
Опенсорс же — сделай если надо. Но скорее всего дело не в самом гцц, а каком нить mingw с которым он сам собран, а сам gcc пользует посиксовый open().
O>>а если нет — НЕФИГ ДЕЛАТЬ ТАКИЕ ПУТИ
BFE>У меня в проекте вложенность каких-то 10 уровней => на длину каталога остаётся каких-то 26 символов. Как при этом работать, если только каталог для .o файлов называется debug-build-gcc-arm-10.3-2021.07-mingw-w64-i686-arm-none-linux-gnueabihf ?
Кхе, вот сделай base64(md5(этой строки)) и будет норм, и информативности не убудет, ведь явно ты тут ниче не читаешь
O>>UPD А нет, если не прокатит — по ссылке выше есть еще параграф 'Enable Long Paths in Windows 10, Version 1607, and Later'
BFE>Потому что длинные пути у меня включены и с ними нет никаких проблем.
BFE>Как это поможет gcc? Никак не поможет.
Там еще манифестик надо вставить в ресурсы ехе-шника.
В манифестике еще стоит попробовать включить поддержку UTF8 для -A функций, глядишь это еще и длинные пути включит — https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
O>>MAX_PATH в винде равен 260,
BFE>Почему MS не переопределить MAX_PATH в 65535 — это отдельный вопрос.
Хотябы потому что он зашит в WIN32_FIND_DATA и скорее всего еще в куче менее известных структур.
O>>чтобы это ограничение обойти, программа должна во-первых использовать wide-версии системных АПИ,
O>>а во-вторых делать путь с префиксом \\?\.
BFE>Это должно делаться автоматически: если префикс отсутствует, то добавляем втихую и работаем.
BFE>Да. Вот я и спрашиваю: есть такая сборка gcc, которая это умеет?
Опенсорс же — сделай если надо. Но скорее всего дело не в самом гцц, а каком нить mingw с которым он сам собран, а сам gcc пользует посиксовый open().
O>>а если нет — НЕФИГ ДЕЛАТЬ ТАКИЕ ПУТИ
BFE>У меня в проекте вложенность каких-то 10 уровней => на длину каталога остаётся каких-то 26 символов. Как при этом работать, если только каталог для .o файлов называется debug-build-gcc-arm-10.3-2021.07-mingw-w64-i686-arm-none-linux-gnueabihf ?
Кхе, вот сделай base64(md5(этой строки)) и будет норм, и информативности не убудет, ведь явно ты тут ниче не читаешь