Runtime: Поддержка FreeBSD

Похоже, есть согласие относительно https://github.com/dotnet/corefx/issues/1576 .

Когда у нас также будет решение по https://github.com/dotnet/corefx/issues/1625, мы сможем начать отправку некоторого кода.

Команда порта достигла соглашения по dotnet / runtime # 14536, если MSFT не выберет иное, это будет FreeBSD . Проблема dotnet / corefx # 1999 потенциально будет проблемой, которая вводит определение в общедоступный API.

Команда порта достигла соглашения по dotnet / runtime # 14536, если MSFT не выберет иначе, это будет FreeBSD.

Если я правильно прочитал, это означает, что при объединении https://github.com/dotnet/corefx/pull/1999 мы можем считать, что этот MSFT одобряет новый общедоступный API, и поэтому можем продолжить решение оставшихся проблем с регулярные запросы на вытягивание без утверждения MSFT.

Если так, мне это нравится.

Следующие шаги согласно https://github.com/dotnet/corefx/pull/1999#issuecomment -111279577:

1. «Команда порта FreeBSD» продолжает свою работу по созданию FreeBSD-версии CoreFX (отслеживается dotnet / corefx # 1626).
2. Команда порта поднимает достаточно стека CoreFX и CoreCLR на FreeBSD, чтобы мы могли запускать модульные тесты CoreFX на FreeBSD.
3. Тесты достигают минимального уровня качества. Я пока точно не знаю, как это выглядит, но полагаю, это означает, что большинство тестов прошло успешно. В идеале у нас не должно быть нескольких специальных тестов, отключенных только для FreeBSD (по сравнению с Linux и OSX, мы бы не хотели, чтобы FreeBSD соответствовала более высоким стандартам, чем другие платформы * NIX, которые у нас есть).
4. Работая с командой порта FreeBSD, команда CoreFX добавляет тесты CoreFX в нашу систему CI, работающую на FreeBSD.
5. Обсудите слияние PR на основе проблемы dotnet / runtime # 14536, которая добавляет свойство.

Мне это кажется вполне разумным планом.

Хорошо, тогда давайте начнем работать над тем, чтобы corefx заработал.

Первое препятствие при сборке corefx на FreeBSD - моно. Сценарий сборки утверждает, что требуется версия 4.1. @ajensenwaud поработал над этим на хосте во Франкфурте, но я не уверен, насколько это полно.

Я сейчас поставлю сборку в очередь и посмотрю, как будет выглядеть результат.

Изменить: сборка (моно) вылетает со следующим кикером в конце:

Making all in mini
make[1]: "/usr/home/josteink/mono/mono/mini/Makefile" line 2906: warning: duplicate script for target "%.exe" ignored
make[1]: "/usr/home/josteink/mono/mono/mini/Makefile" line 2899: warning: using previous script for "%.exe" defined here
  CC       genmdesc-genmdesc.o
In file included from genmdesc.c:9:0:
mini.h:17:34: fatal error: ./mono/metadata/loader.h: Too many levels of symbolic links
 #include <mono/metadata/loader.h>
                                  ^
compilation terminated.
*** Error code 1

Stop.
make[1]: stopped in /usr/home/josteink/mono/mono/mini
*** Error code 1

Stop.

Первое препятствие при сборке corefx на FreeBSD - моно

FWIW, я лично не думаю, что это первое препятствие. Есть две проблемы, связанные со сборкой:

1. Сборка сборок, корректно работающих на FreeBSD
2. Сборка этих сборок на FreeBSD

(1) имеет решающее значение, и я считаю, что эта проблема предназначена для решения этой проблемы. (2) очень приятно иметь, но его отсутствие не мешает созданию отличной системы для запуска управляемого кода на FreeBSD.

Вы, конечно, можете расставить приоритеты, как считаете нужным, но я бы рекомендовал сосредоточиться на (1), а не на (2).

Обратите внимание, что у нас все еще есть проблемы со сборкой corefx в Linux и с OSX, так что наша система CI собирает сборки для этих платформ в Windows; Затем он перемещает полученные сборки на целевую платформу для выполнения тестов.

Это достаточно честно. Я просто предположил, что было бы легче получить общую поддержку платформы FreeBSD, встроенную в corefx, если бы мы действительно могли создать ее самостоятельно на FreeBSD.

Я пока обойдусь со сборкой, инициированной Windows, и попытаюсь вместе создать конфигурацию сборки.

@josteink, кстати. corefx теперь должен основываться на Mono 4.0.1.44.

@akoeplinger Приятно. Это оставляет мне некоторую надежду, что мы сможем запустить его и на FreeBSD :)

Хорошие моменты. Однако, если мы действительно хотим, чтобы corefx был частью среды FreeBSD, нам действительно нужно, чтобы он мог компилироваться из исходного кода, чтобы передать его в систему портов.

Я слышал, что Mono 4.0.1.44 исправляет многие из этих проблем, но у меня еще не было времени поиграть с этим. Я знаю, что команда портов обновляет Makefile порта, и мы говорим о новом патче.

12 июня 2015 года в 20:21 Стивен Туб [email protected] написал:

Первое препятствие при сборке corefx на FreeBSD - моно

FWIW, я лично не думаю, что это первое препятствие. Есть две проблемы, связанные со сборкой:

Сборка сборок, корректно работающих на FreeBSD
Сборка этих сборок на FreeBSD
(1) имеет решающее значение, и я считаю, что эта проблема предназначена для решения этой проблемы. (2) очень приятно иметь, но его отсутствие не мешает созданию отличной системы для запуска управляемого кода на FreeBSD.

Вы, конечно, можете расставить приоритеты, как считаете нужным, но я бы рекомендовал сосредоточиться на (1), а не на (2).

Обратите внимание, что у нас почти нет corefx build-on-Linux и build-on-OSX, так что наша система CI собирает сборки для этих платформ в Windows; Затем он перемещает полученные сборки на целевую платформу для выполнения тестов.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Да, я ни в коем случае не возражаю ... возможность _build_ corefx в Linux, OSX и FreeBSD важна. Я просто предполагаю, что с точки зрения приоритетов важнее иметь возможность действительно _ запустить_ corefx в Linux, OSX и FreeBSD. : wink: Если и то и другое можно работать параллельно, тем лучше.

@ghuntley ,
было бы супер: cool: если бы у нас был контрольный список задач по уценке, в котором было бы указано, что осталось:

- [x] task 1
- [ ] task 2
- [ ] task 3

отображается как:

• [ ] задание 1
• [] задача 2
• [] задача 3

Это, вероятно, подтолкнет других к совершению этих подвигов, и поддержка FreeBSD появится раньше, чем ожидалось! :солнечные очки:

Насколько мне известно, для поддержки FreeBSD требуются следующие части работы в CoreFX:

• [x] Знакомство с платформой FreeBSD со средствами сборки и скриптами. (Сделано @josteink и мной, PRs dotnet / corefx # 2021 объединены, dotnet / corefx # 2030 объединены)

13 Сборки не компилируются сами по себе и требуют изменений, специфичных для FreeBSD. В основном части Interop, которые уже существуют для Linux / OS X (в порядке появления в выходных данных сборки):

• [x] System.Private.URI (готово, PR dotnet / corefx # 2032 объединен)
• [x] System.Console (готово, PR dotnet / corefx # 2031 объединен)
• [x] System.Diagnostics.Debug (готово, PR dotnet / corefx # 2039 объединен)
• [x] System.Diagnostics.Process (обсуждение dotnet / corefx # 2070, PR dotnet / corefx # 3257)
• [x] System.IO.Compression.ZipFile (готово, PR dotnet / corefx # 2041 объединен)
• [x] System.IO.FileSystem.DriveInfo (обсуждение dotnet / corefx # 2526, PR dotnet / corefx # 2606)
• [x] System.IO.FileSystem.Watcher (обсуждение dotnet / corefx # 2046, PR dotnet / corefx # 3257)
• [x] System.IO.FileSystem (готово, PR dotnet / corefx # 2049 объединены)
• [x] System.IO.MemoryMappedFiles (обсуждение dotnet / corefx # 2527, PR dotnet / corefx # 3143)
• [x] System.IO.Pipes (обсуждение dotnet / corefx # 2528, PR dotnet / corefx # 2974)
• [x] System.Net.NameResolution (обсуждение dotnet / corefx # 2988, PR dotnet / corefx # 3471)
• [x] System.Security.Cryptography.Hashing.Algorithms (готово, PR dotnet / corefx # 2040 объединен)
• [x] System.Security.SecureString (готово, PR dotnet / corefx # 2039 объединены)
• [x] System.Runtime.Environment (заблокировано dotnet / corefx # 1999)
• [x] System.Runtime.InteropServices.RuntimInformation (готово, PR dotnet / corefx # 2068 объединены)

Я постараюсь обновить этот список на основе открытых и объединенных PR.

К вашему сведению: PR dotnet / corefx # 2039 объединены

Просто пытаюсь быть здесь на опережение ... Как мы планируем реализовать System.IO.FileSystem.Watcher ?

В Iirc FreeBSD нет inotify , как в Linux и Windows (именно поэтому в последний раз, когда я проверял, нет Dropbox). Будет ли это потенциальным источником неприятностей на нашем пути? Или у кого-нибудь есть идея, как это обойти?

Я предлагаю на время отказаться от этого и выбросить исключение PlatformNotSupportedException, как предложил Стивен Туб в другой теме (https://github.com/dotnet/corefx/pull/2021#issuecomment-111602342). Тогда у нас есть по крайней мере полный набор сборок, и мы можем продолжить работу над этой конкретной проблемой, не блокируя дальнейшие шаги.

Не могли бы вы открыть для этого отдельный выпуск?

Переместим обсуждения System.IO.FileSystem.Watcher в dotnet / corefx # 2046

Ребят есть такой блокировщик на System.Diagnostics.Process ?

@ jasonwilliams200OK рано утром добавил FreeBSD в S.RT.I.RI, который был объединен, но тесты FreeBSD в CheckPlatformTests пришлось откатить до обновления dotnet/buildtools .

• [] Обновите инструменты сборки для поддержки FreeBSD - https://github.com/dotnet/buildtools/pull/180
• [] Повторно примените тесты [Fact,PlatformSpecific(PlatformID.FreeBSD)] к CheckPlatformTests - см. Https://github.com/dotnet/corefx/pull/2068#discussion_r32570244 и https://github.com/dotnet/corefx/pull/2068#discussion_r32570244
• [] Добавьте public static OSPlatform FreeBSD в https://github.com/dotnet/corefx/pull/2068

@ jasonwilliams200OK вчера вечером было несколько обсуждений по поводу System.Diagnostics.Process в gitter, которые были формализованы в https://github.com/dotnet/corefx/issues/2070

@ghuntley , спасибо. Я действительно читал эти сообщения. System.Diagnostics.Process - хитрый вопрос. AFAIK, команда io.js столкнулась с аналогичными проблемами с управлением процессами FreeBSD. Команда Mono, вероятно, справилась с этим, так что @akoeplinger и компания. может просветить нас по этому поводу? :)

System.IO.FileSystem.DriveInfo

Как обсуждалось в gitter, для этого я попытался изучить базовое использование getmntinfo :

#include <sys/param.h>
#include <sys/ucred.h>
#include <sys/mount.h>
#include <stdio.h>

int main() {
  struct statfs *mntbuf;
  int mntsize = getmntinfo(&mntbuf, MNT_NOWAIT);

  for( int i = 0; i < mntsize; i++ ) {
    printf("%s\n", mntbuf[i].f_mntonname);
  }
}

Запуск этого образца дал следующий результат:

$ ./a.out
/
/dev
/tmp
/usr/home
/usr/ports
/usr/src
/var/crash
/var/log
/var/mail
/var/tmp
/dev/fd
/usr/compat/linux/proc
/proc
$

Кажется, он делает то, что нам нужно. Вопрос в том, должны ли мы выполнять какую-либо фильтрацию результатов?

Глядя на «намерение» объекта DriveInfo , пришедшего из мира .NET для Windows, он часто заключался в перечислении доступных мест для хранения или извлечения файлов ( C: , D: и т. д.). Но при использовании иерархических файловых систем Unix возврата / было бы достаточно для удовлетворения этих потребностей.

Итак, что мы должны вернуть? Что было бы полезно? Стоит даже считать это полезным или нет?

Версия для Linux просто сбрасывает все, кроме того, что игнорируется:

https://github.com/dotnet/corefx/blob/master/src/System.IO.FileSystem.DriveInfo/src/System/IO/DriveInfo.Linux.cs#L98 -L99

Я попытался вставить следующий фильтр, но он ничего не изменил с точки зрения вывода:

    if ((mntbuf[i].f_flags != MNT_IGNORE)) {
        printf("%s\n", mntbuf[i].f_mntonname);
    }

Есть мнения?

@josteink , отличные раскопки! Основываясь на https://github.com/dotnet/corefx/issues/815#issuecomment -113825960 и https://github.com/dotnet/corefx/issues/1729 , я думаю, что мы должны сотрудничать с @sokket, чтобы придумать решение работает в разных Unix.

У меня есть версия, работающая на OSX, которая использует getmntinfo и statfs для получения информации о каждой точке монтирования, что кажется наиболее логичным отображением из концепции Windows Drive. Я дважды проверю, соответствуют ли определения функций и структур в OSX определениям FreeBSD, и если это так, моя фиксация для OSX будет работать и для BSD.

Обязательно добавлю тебя в свой пиар @josteink

Звучит отлично. Спасибо за внимание и спасибо за то, что проявили любовь к FreeBSD.

Я изучил некоторые базовые функции pinvoke для этих функций, и кажется, что нам нужно выполнять все упорядочивание и преобразование самостоятельно, так что если кто-то уже приложил усилия, кто я такой, чтобы сказать «нет»? ;)

Нет проблем ... похоже, основное различие было в объявлениях структур; так как в будущем мы, вероятно, столкнемся с этим больше, я провожу некоторый рефакторинг, который позволит нам совместно использовать многие сигнатуры PInvoke. Я добавлю более подробное описание в свой PR (сегодня или завтра, в зависимости от того, как проходит тест), но я в основном добавил подписи PInvoke и структурные подписи для FreeBSD (на основе заголовков, которые я нашел в Интернете), и он компилируется. Я тестировал его на Mac, поэтому он _должен_ (теоретически ...) работать на FreeBSD, так как это всего лишь изменение объявления структуры, но ваш пробег может отличаться :). Если этого не произойдет, у вас будет класс DriveInfo и PInvokes 99% пути, и вам просто потребуется некоторая настройка, основанная на нюансах FreeBSD.

Отличная новость @sokket. Я создал вам учетную запись на машине, которую команда портов использует для разработки, она европейская, но всегда включена и имеет кучу памяти и вычислительной мощности. Надеюсь, это поможет и устранит некоторые проблемы при работе с FreeBSD.

# ssh [email protected]

Парольная аутентификация отключена, используйте один из ваших ключей .

@josteink см. также проблему: https://github.com/dotnet/corefx/issues/815 (System.IO.FileSystem.DriveInfo для Mac / FreeBSD)

Есть ли обновления? Кто-нибудь реализовал остальные сборки на FreeBSD?

Я была занята уходом за своим новорожденным, у меня не было времени нигде программировать.

Я подозревал, что подобные проблемы лежали в бездействии, и я думаю, это в определенной степени это подтверждает.

Для сборок, которые еще не реализованы, я связал вопрос «как реализовать» в списке выше. Я надеюсь, что это поможет координировать усилия по реализации оставшихся сборок.

Я должен признать, что мне было трудно отслеживать, что мы сделали и где, так что это определенно хороший ход. Молодец :)

Где мне это найти? Был бы рад получить остальные сборки
реализовано.

25.07.15 в 22:10 Ян Хенке написал:

Для сборок, которые еще не реализованы, я связал "как
для реализации "-выпуска из приведенного выше списка. Надеюсь, это поможет в координации
усилия по реализации этих оставшихся сборок.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/dotnet/corefx/issues/1626#issuecomment -124838781.

Этот комментарий здесь: https://github.com/dotnet/corefx/issues/1626#issuecomment -111800540

Прямо сейчас я жду завершения работы с собственными прокладками, так как они должны взять на себя большую часть работы по обеспечению работы этих сборок во FreeBSD.

@nguerrera было бы здорово, если бы вы могли держать нас в курсе прогресса. :)

Обновлять:
@janhenke подтвердил, что после объединения https://github.com/dotnet/corefx/pull/2974 , System.IO.Pipes строится на FreeBSD! :солнечные очки:

Обновлять:
dotnet / corefx # 2527 закрыто, System.IO.MemoryMappedFiles строится на FreeBSD.
Спасибо @janhenke за подтверждение!

Благодаря подходу с прокладками все сводится к тому, чтобы убедиться, что эти оболочки компилируются во FreeBSD. К счастью, это делает жизнь намного проще. :)

dotnet / corefx # 3257 должен принести нам как System.Diagnostic.Process и System.IO.FileSystem.Watcher оставив только System.Net.NameResolution неразрешенными. (Я проверю две упомянутые сборки после того, как PR будет объединен и будет работать на FreeBSD)

dotnet / corefx # 3471 должен принести нам System.Net.NameResolution и завершить список выше.

dotnet / corefx # 3471 был только что объединен :)

@sokket , спасибо за обновление. Я создал мастер (f467911) на FreeBSD, используя это руководство: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24. Текущий блокировщик - https://github.com/dotnet/buildtools/issues/292, который исправлен в восходящем потоке, но ожидает следующего развертывания buildtools. :)

Обновление: новые инструменты сборки с исправлением для dotnet / buildtools # 292 приземлились в мастере CoreFX. Следующая остановка от buildtools - https://github.com/dotnet/buildtools/issues/300 : отсутствует специальный инструмент для ОС, позволяющий запускать тесты.

@janhenke , вы отметили System.Diagnostics.Process (# 2070) и System.IO.FileSystem.Watcher (# 2046) как выполненные; но они не реализованы и не компилируются на FreeBSD. Вы действительно проверили список, скомпилировав управляемый код?

Основываясь на моем недавнем опыте с commit 60c78da3c918b0d256cc1f878de06d351dbe3342 (см. Msbuild.log ), следующие сборки не компилируются:

• System.Diagnostics.Process
• System.Diagnostics.ProcessManager
• System.Diagnostics.ThreadInfo
• System.IO.FileSystemWatcher
• System.Net.SocketAddress _ (хорошо, недавно добавили) _

Насколько я помню, я проверил компиляцию связанных прокладок. Поскольку в управляемом коде не должно быть кода, специфичного для FreeBSD. Упомянутые вами прокладки должны быть убраны с помощью PR, указанных выше.
Но я также выполнил полную компиляцию между ними. По крайней мере, System.Diagnostics.ThreadInfo и System.IO.FileSystemWatcher компилировались. Так что, должно быть, что-то пошло не так.

Упомянутые вами прокладки должны быть убраны с помощью PR, указанных выше.

Собственно, PR https://github.com/dotnet/corefx/pull/3257 не имеет отношения к прокладке. В управляемых проектах все еще есть код PAL (старый подход), поэтому для полной уверенности необходимо создавать управляемые сборки.

Собственно, PR dotnet / corefx # 3257 не имеет отношения к шиму.

Я не согласен. Он выполняет рефакторинг кода P / Invoke для совместимости с оболочкой System.Native. Кроме того, как я редактировал выше, я вспоминаю по крайней мере некоторые сборки, скомпилированные между ними.

я не согласен

https://github.com/dotnet/corefx/pull/3257/files : см. экземпляры .Unix.cs и .Linux.cs для System.Diagnostics. . Обратите внимание, что .OSX.cs остается нетронутым.

Он выполняет рефакторинг кода P / Invoke в оболочку System.Native.

Да, он выполняет рефакторинг некоторых общих помощников под System.Native , но не System.Diagnostics.* и др.

Даже когда эти сборки представляют собой только P / Invoking to System. * Libs, для некоторых из них может потребоваться работа FreeBSD, например, System.Diagnostics.Process и System.IO.FileSystem.Watcher. Они используют функции, специфичные для Linux и OS X, и мы не планируем пытаться абстрагироваться от них за собственными прокладками. Целью прокладок не является создание единого управляемого двоичного файла для Unix, хотя это очень хорошее свойство, когда оно возникает в процессе работы; основная цель - избежать различий в ABI, которые вызывают нестабильность. Я ожидаю, что по крайней мере несколько сборок по-прежнему будут иметь двоичные файлы, специфичные для Linux / OS X, где также потребуется двоичный файл FreeBSD.

К вашему сведению, нет сборок corefx с именем System.Diagnostics.ProcessManager,
System.Diagnostics.ThreadInfo,
System.IO.FileSystemWatcher или
System.Net.SocketAddress. Это типы в других сборках.

Я ожидаю, что по крайней мере несколько сборок по-прежнему будут иметь двоичные файлы, специфичные для Linux / OS X, где также потребуется двоичный файл FreeBSD.

Означает ли это, что когда появятся Solaris и non-glibc (musl и μlibc), нацеленные на Linux, такие как поддержка Alpine, у них будут отдельные двоичные файлы? И тогда для разных архитектур ARM, MIPS, RISC, SPARC и т. Д. Потребуется другой уровень разделения?

Разве не имеет смысла сводить их к интерфейсу / системным вызовам POSIX в максимально возможной степени и обнаруживать различия с помощью конфигураций (через CMake) для использования в одном и том же двоичном файле (если это не влияет на размер / производительность сборки существенно)? Насколько я понял, у двоичного файла System.Native.so есть общий помощник для других конкретных System.*.Native.so который кажется достаточным для соблюдения принципа разделения проблем. Но если он преобразуется в System.Net.Http.FreeBSD.ARM.Native.so или System.Net.Http.Solaris.SPARC.so , тогда он будет совершенно неуправляемым со «слишком большим количеством движущихся частей» и т. Д.

нет сборок corefx с именем

Хорошая точка зрения. На самом деле я просматривал экземпляры сбоев в журналах msbuild и количество файлов .OSX.cs и .Linux.cs . :улыбка:

Разве не имело бы смысла максимально свести их к интерфейсу / системным вызовам POSIX?

Мы делаем. Как вы предлагаете хорошо следить за файлами через POSIX? Как вы предлагаете нам хорошо обрабатывать перечисление через POSIX?

Но если он будет преобразован в System.Net.Http.FreeBSD.ARM.Native.so или System.Net.Http.Solaris.SPARC.so, тогда он будет совершенно неуправляемым со «слишком большим количеством движущихся частей» и т. Д.

Я этого не понимаю. Вся суть собственных файлов .so в том, что вы получаете разные собственные двоичные файлы для каждой целевой платформы, но они не называются System.Whatever.Platform.ext, а просто System.Whatever.ext; что позволяет компилятору взять ту же общую логику и использовать ее с определениями, специфичными для этой платформы. Это работает, только если на каждой платформе существуют одинаковые символы; компилятор не берет волшебным образом код, написанный для использования inotify, и не позволяет ему работать с интерфейсом просмотра файлов из какой-либо другой системы. В общем, мы очень старались использовать стандартизированные API там, где это имеет смысл, но для мест, где такие API не существуют или недостаточно стандартизированы, или где есть лучшие решения для конкретной платформы, мы использовали лучшую платформу - конкретные решения, например, использование procfs для перечисления процессов в Linux, использование inotify для наблюдения за файловой системой в Linux и т. д. Живет ли такая логика, зависящая от платформы, в управляемом или собственном коде, на самом деле не имеет значения с точки зрения простоты переноса на- с точки зрения дополнительных платформ, например, когда появляются эти новые платформы, если существующие API работают, то работает и существующее решение, а если нет, то вам нужно написать новое решение для этой платформы. И поэтому мы постарались сделать как можно больше в управляемом коде, просто используя нативный код для прокладок 1: 1, которые делают этот управляемый код намного более переносимым там, где переносимы целевые API. Мы использовали #ifdefs в собственном коде, чтобы скрыть мелкие детали, где этот API на какой платформе достаточно близок к этому API на другой платформе, но это не распространяется на целые решения, которые полностью отличаются; в этот момент абстракция становится управляемым API, и мы делаем разные управляемые реализации для каждой системы.

Если FreeBSD предоставляет inotify, как Linux, или если он предоставляет EventStream, как OS X, тогда, когда эти API-интерфейсы ОС находятся за оболочкой, оболочку можно легко настроить для работы с FreeBSD, и тот же управляемый двоичный файл можно использовать во FreeBSD. Если FreeBSD не предоставляет такие API-интерфейсы, вам необходимо написать собственную реализацию System.IO.FileSystem.Watcher с некоторым решением для просмотра файлов, доступным во FreeBSD. Подобные комментарии для System.Diagnostics.Process. Независимо от того, находится ли код для отслеживания файлов в прокладке или нет, это мало влияет на это.

Планируется, что все такие собственные API-интерфейсы в конечном итоге будут перемещены за прокладку. Но они далеки от приоритета, поскольку они не очень переносимы, и поэтому вы видели, как мы начинали с API из libc, которые (или должны быть) доступны повсюду.

Как вы предлагаете хорошо следить за файлами через POSIX?

Мы не можем сделать все это POSIX, поскольку inotify специфичен для Linux. FreeBSD / OSX предлагает отдельные реализации.

Предложение:

С точки зрения распространения нативных двоичных файлов каждая ОС должна получать одинаковый набор двоичных файлов с одинаковыми именами, но с разной функциональностью.

Вот предлагаемая структура:

# cmake

check_include_files( "inotify.h" HAVE_INOTIFY_ABILITY )

// config.h.in
cmakedefine01 COREFX_HAVE_INOTIFY_ABILITY
// always a good idea to prefix our headers with project id :)

// header (pal_fsw.hpp) file

#pragma once

class file_system_watcher_shim
{
public:
  void common_function_for_posix_compliants();
  void slightly_diverged_function();
  void painfully_diverged_watch_function();
}

// source (pal_fsw_commons.cpp) file

#include "pal_fsw.hpp"

void file_system_watcher_shim::common_function_for_posix_compliants() {
 // TODO: implement common function for all
}

void file_system_watcher_shim::slightly_varied_function() {

#if COREFX_HAVE_XYZ_ABILITY

  // your way

#else

  // my way

#endif // COREFX_HAVE_XYZ_ABILITY

}

// source (pal_fsw_inotify.cpp) file

// this is a separate compilation unit and will clash with others,
// therefore guarding it with preprocessor directive

#if COREFX_HAVE_INOTIFY_ABILITY

#include "pal_fsw.hpp"

void file_system_watcher_shim::painfully_diverged_watch_function() {
 // TODO: implement inotify based watcher
}

#endif // COREFX_HAVE_INOTIFY_ABILITY

// source (pal_fsw_non_inotify.cpp) file

// this is a separate compilation unit and will clash with others,
// therefore guarding it with preprocessor directive

#if !COREFX_HAVE_INOTIFY_ABILITY

#include "pal_fsw.hpp"

void file_system_watcher_shim::painfully_diverged_watch_function() {
 // TODO: implement non-inotify way
}

#endif // !COREFX_HAVE_INOTIFY_ABILITY

По сути, это то, что у нас есть, например

• "common_function_for_posix_compliants" - это встроенные в оболочку функции 1: 1, потребляемые из логики в совместно используемом управляемом двоичном коде Unix.
• "Little_diverged_function" - это встроенные функции почти 1: 1 с встроенной оболочкой, с некоторыми встроенными #ifdef, потребляемыми из логики в совместно используемом управляемом двоичном файле Unix.
• "painfully_diverged_watch_function" - это встроенные функции 1: 1 с встроенной оболочкой, потребляемые из логики в управляемых двоичных файлах, зависящих от платформы.

Реальная разница в том, написан ли код, реализующий «болезненно расходящуюся» логику, на C # или C ++, и мы выбрали C #, и все это уже реализовано на C #. Я не видел убедительных аргументов в пользу того, почему в таких случаях переписывание всего этого на C ++ было бы значительно более убедительным вариантом.

@ jasonwilliams200OK Сегодняшним обновлением до mono я снова собираю corefx на самой FreeBSD. Со времени последней сборки появилось много новых сообщений об ошибках.
Мне интересно, исчезнет ли в конце концов Interop.Libc ?

@stephentoub Все сводится к упаковке. Наличие всего кода, специфичного для платформы, в нативной части дает преимущество наличия одной управляемой сборки для всех Unix-подобных платформ.
Кроме того, я твердо уверен, что нам нужна универсальная реализация для этого управляемого кода, зависящего от платформы. Даже если он просто генерирует NotImplementedExcpetion. Таким образом, вы можете значительно упростить перенос на новые платформы, если он по крайней мере сразу все скомпилирует. Кроме того, это даст шанс хотя бы попробовать запустить на неподдерживаемой платформе.
Как правило, это намного проще, если вы можете хотя бы сразу успешно скомпилировать.

@stephentoub , извините, я смешивал C ++ с C #. Теперь я понимаю, что собственный уровень просто раскрывает эти точки входа (функции собственных библиотек или системные вызовы), а дезинфекция ввода-вывода и управляемого кода - это то место, где мы решаем, какой обернутый служебный метод / обернутый системный вызов для конкретной платформы будет использоваться. Кроме того, оба уровня (собственный и управляемый) не могут быть независимыми от ОС, в которых должны использоваться функции, отличные от POSIX.

@janhenke , согласен. Я тоже строю мастера, пока мы говорим. Есть еще одна повторяющаяся проблема с подписанием сборки, о которой я столкнулся:

CSC : error CS7027: Error signing output with public key from file '/root/corefx/packages/Microsoft.DotNet.BuildTools.1.
0.25-prerelease-00104/lib/ECMA.snk' -- mscoree.dll [/root/corefx/src/System.IO.Compression.ZipFile/ref/System.IO.Compres
sion.ZipFile.csproj]
CSC : error CS7033: Delay signing was specified and requires a public key, but no public key was specified [/root/corefx
/src/System.IO.Compression.ZipFile/ref/System.IO.Compression.ZipFile.csproj]

CSC : error CS7027: Error signing output with public key from file '/root/corefx/packages/Microsoft.DotNet.BuildTools.1.
0.25-prerelease-00104/lib/ECMA.snk' -- mscoree.dll [/root/corefx/src/System.IO.Compression/ref/System.IO.Compression.csp
roj]
CSC : error CS7033: Delay signing was specified and requires a public key, but no public key was specified [/root/corefx
/src/System.IO.Compression/ref/System.IO.Compression.csproj]

вскоре опубликует полную ссылку на msbuild.log.

Кроме того, я твердо уверен, что нам нужна универсальная реализация для этого «зависимого от платформы управляемого кода».

Я согласен. Вместо частичных классов мы, вероятно, можем использовать наследование с общими и в основном общими виртуальными методами в абстрактном базовом классе и при необходимости переопределить "в основном общие / частично разные". Затем реализуйте абстрактные методы, которые полностью различны для каждой ОС. С этим подходом ИМО, если там, где специализация / обобщение теряет DRY'ing, мы можем использовать многоступенчатое наследование предков. Но в прошлый раз, когда я проверил, частичные классы были предпочтительнее родительско-дочерних ассоциаций в CoreFX (почему-то я не помню). :)

Вот файл msbuild.log для фиксации 2d36889:

https://gist.githubusercontent.com/jasonwilliams200OK/b375ce52c7b0c90e24af/raw/c895d405a3044dd6acdb26ec49c4b0ced0c76d1a/corefx-msbuild.log

/ cc: @akoeplinger

@ jasonwilliams200OK Почему так сложно. Все, что ему нужно, это условие «если не Windows, Linux, OS X» в файлах проекта. Так что либо включите в сборку набор файлов для конкретной платформы, либо общие.

Я не думаю, что тот факт, что некоторые сборки не могут собираться / работать для FreeBSD, все же должен быть серьезным препятствием для тестирования остальных из них. Вероятно, нам следует просто сделать так, чтобы те, у которых есть незавершенная работа (FileSystemWatcher, Process, Networking), пропускались при сборке и тестовом запуске во FreeBSD. Затем мы можем поднять их индивидуально, имея процесс предотвращения регресса в том, что уже работает.

Я не думаю, что тот факт, что некоторые сборки не могут собираться / работать для FreeBSD, все же должен быть серьезным препятствием для тестирования остальных из них.

Согласовано

Вероятно, нам следует просто сделать так, чтобы те, которые ожидают работы (FileSystemWatcher, Process, Networking), пропускались при сборке и тестовом запуске на FreeBSD.

Или аналогично тому, что предложил @janhenke , просто разрешите им сборку, либо заглушив файлы, которые бросают PlatformNotSupported, либо просто сопоставив FreeBSD с одним из случаев, которые действительно работают, например, если выбрана FreeBSD, просто создайте Linux ( не сработает, но построится).

Благодаря недавним изменениям @ellismg (# 3684) я могу запускать тесты, упрощая предыдущий метод (https://github.com/dotnet/coreclr/issues/1633#issuecomment-143669303):

• После https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 (особенно шага по созданию собственных прокладок отдельно _ после_ выхода build.sh со статусом 1) загрузите архив артефактов CoreCLR : cd /root; curl -o bins.zip "http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/debug_freebsd/lastSuccessfulBuild/artifact/*zip*/archive.zip (не забудьте кавычки вокруг URL), а затем unzip bins.zip; chmod -R 0777 archive/; rm bins.zip; cd corefx .

(от машины с Windows ничего не требуется)

• Провел тест:

./run-test.sh \ --coreclr-bins ../archive/bin/Product/FreeBSD.x64.Debug \ --mscorlib-bins ./packages/Microsoft.DotNet.CoreCLR/1.0.0-prerelease/lib/aspnetcore50 \ --corefx-native-bins ./bin/FreeBSD.x64.Debug/Native

Он говорит:

40 тестов не пройдены

Я не думаю, что тот факт, что некоторые сборки не могут собираться / работать для FreeBSD, все же должен быть серьезным препятствием для тестирования остальных из них.

Я должен согласиться с этим. Лучше начать QAing проделанной работы, чем ждать, пока все будет завершено, прежде чем начинать тестирование.

Он говорит: 40 тестов не пройдены

40 из скольких? На каком мы этапе? :)

40 из скольких? На каком мы этапе? :)

меня тоже бьет. Тесты создаются из тестовых сборок (управляемых DLL), и общее количество тестов не отображается.

Число, полученное сценарием в конце, - это количество тестовых сборок, которые не прошли проверку. xUnit должен записывать количество неудачных тестов для каждой сборки в stdout как часть своего запуска. Номера также должны быть в файлах XML, которые он создает в каждой папке тестовой сборки.

Возможно, среда выполнения также просто дает сбой, и в этом случае могут не создаваться журналы для каждой тестовой сборки.

@ jasonwilliams200OK Знаете ли вы, был ли достигнут какой-либо прогресс в вопросе подписания сборки? Я попадаю в то же самое на Ubuntu. Если над этим никто не работает, возможно, стоит открыть для него отдельный выпуск.

@naamunds , которая была исправлена ​​на мастере CoreFX в рамках https://github.com/dotnet/corefx/issues/3739.

Обновление - Сегодня я провел тесты на FreeBSD, тысячи из них проходили, а затем некоторые терпели неудачу из-за очевидного отсутствия System.Diagnostics.Process и друзей snafu. После ~ 40 минут успешного выполнения он завис на тестах System.IO.FileSystem (примерно на ~ 15 минут, прежде чем я нажал Ctrl + C для завершения).

@ jasonwilliams200OK как вам удалось собрать corefx под freebsd? Я застрял в ошибках по поводу gssapi

@sec , на момент создания этих заметок: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 , GSSAPI не требовался CoreFX. Однако похоже, что пакет pkg недавно перенесен на FreeBSD: http://www.freshports.org/security/p5-GSSAPI. Вы можете попробовать pkg upgrade pkg && pkg update && pkg install p5-GSSAPI .

@ jasonwilliams200OK , я уже получил это (это perl ext. btw.) Проблема отсутствовала gssapi_ext.h. Уловка заключалась в том, чтобы выполнить команду «pkg install krb5» - теперь она скомпилирована в собственном коде.
Я скопировал их в среду выполнения coreclr, но все еще не могу запустить приложение ASP.NET Core :) Тогда борьба продолжается.

Каков текущий статус этой задачи? Список @janhenke полон и точен? Вся необходимая работа сделана? Тогда его надо закрыть, да?

Если да, то почему у нас все еще есть эта задача? https://github.com/dotnet/corefx/issues/2070

Если работа еще предстоит, следует ли регистрировать новую проблему с учетом текущего положения дел?

Думаю, это тоже необходимо - dotnet / corefx # 2046

следует ли регистрировать новый выпуск исходя из текущего положения дел?

Да: +1:

Мы обсудили управляемый сообществом перенос FreeBSD с @wfurt (из команды .NET Core), которые оба проявили интерес к работе.
Вот предложение по плану, которое мы составили (отзывы / предложения приветствуются):

1. Создавать двоичные файлы в репозитории CoreCLR и CoreFX для FreeBSD - можно использовать хаки
   
   
   
   • Трудно распараллелить, @wfurt будет работать над этим
   
   
   • Сборка может быть смесью сборок с других платформ (Mac, Linux), нацеленных на FreeBSD.
   
   
   • Нам потребуются задокументированные шаги (на вики FreeBSD), чтобы воспроизвести сборку с исправлениями ошибок, характерных для FreeBSD.
   
   
2. Запуск и стабилизация тестов CoreCLR (с использованием corerun)
   
   
   
   • Тесты могут быть построены на другой платформе
   
   
   • Цель: Обеспечивает базовое качество выполнения.
   
   
3. Запуск и стабилизация тестов CoreFX (с использованием corerun)
   
   
   
   • Тесты могут быть построены на другой платформе
   
   
   • Обратите внимание, что для этого требуется xunit. Основываясь на нашем прошлом опыте портирования, мы полагаем, что после завершения [2] xunit будет работать.
   
   
   • Теоретически это можно распараллелить с [2] - это может потребовать сокращения xunit (например, сгенерировать статический рецепт выполнения на другой платформе)
   
   
4. Сборка полного стека на FreeBSD (с использованием corerun в качестве загрузчика из [1] - [3])
   
   
   
   • Нам понадобятся все инструменты (nuget, msbuild, roslyn) для работы над усилением .NET Core.
   
   
5. Установщики (порты FreeBSD)
   
   
   
   • Первый этап: использование двоичных файлов продуктов из каналов nuget
   
   
   • Второй этап: сборка продукта из исходного кода (блокируется при сборке из исходного кода)
   
   
   • Требуется опыт сообщества FreeBSD и руководство по дизайну
   
   
   • Примечание: мы можем связывать пакеты FreeBSD также с официальных страниц загрузки .NET Core в качестве пакетов поддержки сообщества.
   
   
6. Регулярная сборка и тестирование FreeBSD
   
   
   
   • Цель: убедиться, что изменения в репозиториях .NET Core, нарушающие работу FreeBSD, известны заранее.
   
   
   • Необходим дизайн
   
   
   • Требуется опыт сообщества FreeBSD и руководство по дизайну
   
   

Принципы работы:

• Изменения в [2] - [4] следует делать в первую очередь в репозиториях CoreCLR / CoreFX (из-за требований подписи CLA, проверки кода экспертами / членами группы .NET Core и т. Д.)
• Мы будем отслеживать работу на высоком уровне по этому вопросу. Конкретные ошибки будут зарегистрированы как отдельные проблемы.

Если кто-то хочет помочь, сообщите нам об этом здесь. Мы можем легко распределить рабочие элементы из [2] и [3] выше, как только мы достаточно далеко продвинемся с [1].

Последняя версия предложения находится в верхней части этого номера.

Отметка других людей, проявивших интерес к списку freebsd-mono ( эта ветка ): @smortex @radovanovic @ Echo-8-ERA

Кстати: я не могу найти учетную запись Mathieu Prevot GitHub - [ОБНОВЛЕНИЕ] Найдено в https://github.com/dotnet/corefx/issues/1626#issuecomment -330348424: @mprevot

Что касается NetBSD, нам не хватает надежных мьютексов posix, это единственная функция, которая до сих пор отсутствует для создания именованных мьютексов robus. Теперь мы можем отлаживать сбои управляемого кода с помощью LLDB / NetBSD ... он отлично работает с файлами ядра. В моих предыдущих попытках мы умерли из-за отсутствия этой функции в LLDB (я начал портировать этот отладчик для .NET).

Лучшая поддержка FreeBSD значительно поможет.

В прошлом также были проблемы с отсутствием поддержки гостевых гипервизоров для подключения сборщика NetBSD к машинам CI и проверки исправлений ... для этого мне может потребоваться помощь от MS. Я ожидаю, что для его запуска требуется проприетарное программное обеспечение, которым я не владею ... Я мог бы найти разработчика для выполнения этой работы, если бы между NetBSD Foundation и Microsoft возникла совместная заинтересованность (инвестиции).

Где мы упускаем «надежные мьютексы posix»? Является ли это частью .NET Core PAL?

О какой системе CI вы имеете в виду? Почему это связано с усилиями по переносу .NET Core?

Где мы упускаем «надежные мьютексы posix»?

В ядре NetBSD (и libc / libpthread) это часть CoreCLR. FreeBSD разработала его за последние два года. Он может быть доступен в последней стабильной версии ... но необходимо проверить.

Я хочу добавить эту функцию перед перезапуском портирования .NET. (Также был обнаружен крошечный недостающий API для сетевой маршрутизации ... но сейчас я его пропускаю).

Является ли это частью .NET Core PAL?

Я не помню сейчас, без проверки кода - это API, используемый для реализации .NET с именами устойчивых мьютексов (или, возможно, семафоров).

О какой системе CI вы имеете в виду?

NetBSD.

Почему это связано с усилиями по переносу .NET Core?

В прошлый раз, когда я смотрел, это была дополнительная функция. Я решил добиться паритета функций для интерфейсов ядра и утилит (например, LLDB). Просто мой стиль работы - получить функциональный строительный блок, а потом построить дом. В какой-то момент он нам все равно понадобится, так почему бы не разработать его за один раз. Спасибо за понимание :)

Может быть, вы можете просто пометить группу freebsd-dotnet на GH? Он там является участником (или вы можете посмотреть имя его учетной записи). Его электронная почта: [email protected]

[РЕДАКТИРОВАТЬ] Удалить сообщения электронной почты и предыдущий ответ от @karelz

@RussellHaley не стесняйтесь помечать большую группу, если считаете, что это уместно. Мне не удалось найти учетную запись Mathieu GH ни по его имени, ни по электронной почте, это то, что я имел в виду выше (BTW: я написал ему напрямую по электронной почте).

Я посмотрю, как пометить группу.

Вот счет Матье. Возможно, настройка конфиденциальности?

https://github.com/mprevot

Ваше здоровье,

Русь

В понедельник, 18 сентября 2017 г., в 13:01, Карел Зикмунд [email protected]
написал:

@RussellHaley https://github.com/russellhaley не стесняйтесь помечать
большая группа, если вы считаете, что это уместно. Я не мог найти GH Матье
через его имя или адрес электронной почты, это то, что я имел в виду выше.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/corefx/issues/1626#issuecomment-330338996 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ACENF_N6mtOo3fptvku-LUMioNpZG7coks5sjswWgaJpZM4EPG-N
.

Я нигде не вижу здесь упомянутого, но на какую самую низкую версию FreeBSD мы здесь нацеливаемся (я предполагаю, что по крайней мере 10 и новее, но, может быть, и 9)?
(Я также немного запутался, какое обсуждение должно происходить в списке рассылки mono

Что ж, если у вас есть Fedora, MS будет поддерживать только поддерживаемые в настоящее время версии, то есть 10.3 (скоро 10.4) и 11.1.

@radovanovic FreeBSD 9 больше не поддерживается, 10 будет EoL в апреле 2018 года, 11 - в 2021 году. По моему опыту, проблем с компиляцией на 11 vs 10 (и даже 9, если хотите) быть не должно. FreeBSD разрабатывается с учетом обратной совместимости.

@radovanovic Я тоже немного запутался, какое обсуждение должно происходить в списке рассылки

Я ожидал здесь технических обсуждений, координации работы и статуса, так как это более широкая аудитория, чем список рассылки mono @ freebsd . OTOH: мы не хотим иметь миллионы случайных обсуждений по одному вопросу, поэтому мы могли бы выделить некоторые конкретные обсуждения дизайна в отдельные вопросы от этого, если они превысят разумное количество ответов.

Наконец-то я смог запустить тесты corefx на FreeBSD 11.0 (без тестов внешнего цикла)
Всего прошло: 144208
Всего сбоев: 2622
Всего пропущено 207

Я обновлю https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD инструкциями. Я запишу конкретные проблемы и помечу их с помощью os-freebsd и up-for-grab.
Полномасштабная битва может начаться. Нужны волонтеры.

И да, я пропустил предложенный шаг два. Я тоже к этому вернусь.

С некоторыми незавершенными изменениями текущая статистика выглядит так:
Всего прошло: 238892
Всего сбоев: 58
Всего пропущено 1628

System.Runtime.Tests.dll, 1
System.Net.Ping.Functional.Tests.dll, 7
System.Net.NameResolution.Pal.Tests.dll, 3
System.Net.NameResolution.Functional.Tests.dll, 4
System.IO.MemoryMappedFiles.Tests.dll, 1
System.IO.FileSystem.Tests.dll, 7
System.Globalization.Tests.dll, 2
System.Drawing.Common.Tests.dll, 31
System.Console.Tests.dll, 2

dotnet / corefx # 24538 открыт для отслеживания поддержки сломанных чашек.

Большой прогресс! Добавление NetBSD при наличии встроенной поддержки FreeBSD должно быть простым.

@wfurt, пожалуйста, поделитесь адресом электронной почты, я

Первоначальная поддержка была объединена с основной веткой. Сборка должна работать, как описано на странице WIKI.
Я медленно продвигаюсь по dotnet / corefx # 24386, но это не должно сдерживать большинство пользователей.

Можем ли мы уже загрузить .NET на FreeBSD?

Я какое-то время не пробовал @krytarowski Было продвинуто обновление инструментария до версии 2.0, и я ждал, когда эти усилия стабилизируются. Я попробую еще раз и опубликую обновление.

Привет, так что я увяз в том, что управляемые тесты clr не работают. https://pastebin.com/B5KhtKX5

Любой вклад был бы отличным, поскольку это было проблемой в течение некоторого времени. Я также недавно столкнулся с ошибкой сборки при сборке corefx в Windows (master, Git revision 749194e). https://pastebin.com/JXUySLTY

Я предполагаю, что это временная проблема, но сегодня вечером она меня замедлила.

Если вы посмотрите на ошибку:

tests/runtest.sh: line 786: ((: i<: syntax error: operand expected (error token is "<")

И оскорбительная строка кода :

bash for (( i=0; i<$maxProcesses; i++ )); do

Мне кажется, что $maxProcesses не определено, что приводит к неполному логическому выражению:

diff +for (( i=0; i<$maxProcesses; i++ )); do -for (( i=0; i<; i++ )); do

Это должно быть достаточно проверено. И если это так, вам просто нужно отправиться на поиски назад, чтобы попытаться выяснить, как вы оказались в таком положении.

Спасибо за вашу помощь! @josteink :) Вы правы. Патч здесь: https://pastebin.com/d5y9k1tw

Это позволяет запускать тесты, но я отказался от ~ 1000 ошибок одного и того же характера:

ВЫПОЛНЕНО - JIT / Methodical / cast / iface / _il_dbgiface2 / _il_dbgiface2.sh
НАЧАТЬ ИСПОЛНЕНИЕ
/usr/home/russellh/Git/coreclr/bin/tests/Windows_NT.x64.Debug/Tests/coreoverlay/corerun _il_dbgiface2.exe
coreclr_initialize не удалось - статус: 0x80004005
Ожидается: 100
Актуально: 255
КОНЕЦ ИСПОЛНЕНИЯ - НЕ ИСПОЛЬЗУЕТСЯ

Хорошо, согласно отличной информации от @janvorli , я запускал часть своей сборки в выпуске и часть моей сборки в отладке. Досадная ошибка копирования / вставки. Сейчас восстанавливаю.

https://github.com/dotnet/coreclr/issues/1419

Патч здесь: https://pastebin.com/d5y9k1tw

Если у вас есть патч, который исправляет неработающую сборку, я бы рекомендовал отправить его как pull-request, чтобы он был исправлен для всех :)

Спасибо, я сделаю так. Я все еще работаю над запуском тестов, и я не был уверен, что вызвало последующую ошибку прошлой ночью.

Я полагаю, что Freebsd 11 "pkg install" не будет поддерживать netcore 2.1 (после выпуска), не так ли?

TL; DR; Проделано много работы, но нужно, чтобы кто-то отвез ее домой. Написание Makefile порта - самая простая часть.

@wfurt удалось собрать CLR и FX с использованием Linux, но в основном это не было протестировано. Я смог получить «родные» части для сборки на FreeBSD, но остановился на получении управляемых частей для сборки на Windows (для FreeBSD). Все это было беспорядочной передачей файлов между операционными системами.

Отдельно в списке рассылки [email protected] @dragonsa импортировала двоичную версию Dot Net Core 1 и всю цепочку инструментов (msbuild, nuget и т. Д.) Из MintOS с использованием эмуляции Linux. Я мог использовать его патчи и запускать некоторые инструменты, но так и не смог ничего построить. Я не уверен, что эти исправления уже внесены; Я просматривал их и сменил работу. У меня нет DotNet в моей нынешней роли, и я сейчас активно занимаюсь другими делами.

Что все это значит? Если кто-то может проверить патчи @dragonsa , он может зайти в список рассылки https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources-mail.html

@russellhadley Спасибо за

Привет,

Обсуждая это здесь с разработчиком .NET, я готов помочь с разработкой порта / пакета FreeBSD.

Полное раскрытие информации: я не разработчик .NET, однако я готов работать с кем угодно, чтобы внести это в дерево.

~ cy

@cschuber Я был слишком занят, чтобы следить за текущим состоянием вещей, но как человек, который отправил много патчей FreeBSD и сумел запустить Hello World около 3 лет назад, было бы здорово, если бы мы наконец смогли увидеть, как эта штука правильно приземляется. Моя полная поддержка :)

@cschuber , текущие активные проблемы: https://github.com/dotnet/coreclr/issues/18067. В основном эти четыре функции оставлены https://github.com/dotnet/corefx/issues?q=is : open + label: os-freebsd + label : up-for-grabs + is: issue, среди которых, похоже, есть Наблюдатель за файловой системой. самый хитрый / трудоемкий https://github.com/dotnet/corefx/issues/2046.

Спасибо за предложение @cschuber. Мы почти достигли того момента, когда это станет возможным.
Недавно мы работали с @mateusrodrigues, чтобы заставить .net работать с FreeBSD, и он пытается заставить работать PowerShell. Список отправленных @ kasper3 - это в первую очередь недостающие функции. Думаю, сейчас мы можем отказаться от PNSP. На мой взгляд, наиболее актуальными проблемами являются dotnet / corefx # 30698 и https://github.com/dotnet/coreclr/issues/18481. Было бы здорово, если бы кто-нибудь из сообщества смог в них разобраться. В последнее время я не проводил тесты, но боюсь, что количество отказов увеличилось.
Мы должны открывать вопрос для каждой новой группы неудачников.

Я также начинаю исправлять исходную сборку, но впереди все еще есть некоторые проблемы.
Компилятор c # написан на c #. Текущая сборка .net использует предыдущую версию .net для создания управляемых сборок. Это также зависит от пакетов Nuget.
Прямо сейчас у нас есть достаточно хороший bootstrap cli, чтобы мы могли создавать coreclr, corefx и несколько других репозиториев на FreeBSD. Я еще не обновлял инструкции по сборке, чтобы отразить изменения 2.1 и сборку исходного кода.

+1 Просто хочу сказать, что я рад, что у этого все еще есть импульс. С таким количеством движущихся частей сложно следить, но похоже, что люди добиваются прогресса. Некоторое время назад я создал pkg install dotnet && dotnet build один прекрасный день (без совместимости с Linux).

Также с нетерпением жду этого

Сейчас у нас есть ежедневные сборки. Здесь можно получить среду выполнения или SDK: https://dotnetcli.blob.core.windows.net/dotnet/Runtime/master/dotnet-runtime-latest-freebsd-x64.tar.gz и
https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-sdk-latest-freebsd-x64.tar.gz

Также возможно перекрестное нацеливание, например, в Linux или Windows можно сделать dotnet publish -r freebsd-x64 и это создаст автономное приложение FreeBSD.

Он все еще неполный и не поддерживается, но он должен облегчить кому-либо участие.
Было бы здорово, если бы люди могли попробовать, сообщить о проблемах.
Также это было бы хорошее время для последнего толчка, чтобы закрыть пробелы в функциях и исправить ошибки.

Копия: @mateusrodrigues

Отличная работа, @wfurt и @bartonjs.

Когда я предлагал свои первые коммиты FreeBSD около 2-3 лет назад, я на самом деле не верил, что мы до них доберемся, но я определенно хотел попробовать.

Это определенно большая веха, и, надеюсь, поможет новым участникам завершить перенос.

Большое спасибо всем, кто помог нам зайти так далеко 👍

Большой прогресс! Я все еще борюсь с набором инструментов (большинство проектов LLVM, кроме LLDB и LLD, завершены) и аппаратной виртуализацией для NetBSD (Linux / BSD теперь начинает загружаться до фатального исключения VTx, более простые ОС, такие как FreeDOS, уже работают) .. так что я продолжу мое портирование NetBSD, надеюсь, раньше, чем позже. Лучшая поддержка FreeBSD поможет облегчить резюме.

Потрясающие :)

Мы преследуем пьянство, почему бомбежка силосов?

@krytarowski Можете ли вы разработать, каким образом «поддержка FreeBSD» может быть лучше?

Было бы здорово, если бы какой-нибудь гуру FreeBSD мог взглянуть на https://github.com/dotnet/coreclr/issues/22124. Я бы ожидал, что сборка двоичных файлов для 11 будет запускаться на 12, но, похоже, это не так; (
Его легко воспроизвести с помощью простого приложения, а версия 12.0, похоже, ломает то, от чего зависит dotnet.

Привет, я не гуру, но мы столкнулись с регрессией потоков в 12-RELEASE в порту Lua53.
См. Здесь исходную ошибку: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235158
и здесь для обнаруженной ошибки базовой системы: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235211 (обратите внимание, что ошибка базовой системы определяет код, который можно использовать для воспроизведения проблемы для сравнения).

Исправление для Lua заключается в связывании с -pthread, хотя от Lua для -pthread не требуется НУЛЯ.

спасибо @RussellHaley. Это выглядит многообещающим.

Рад, что смог помочь. Я бы хотел подыграть, но у меня едва хватает нескольких часов на обслуживание порта Lua. Продолжайте в том же духе!

Как тот, кто исправил реализацию потоковой передачи FreeBSD в coreclr , я думаю, что pthreads используются довольно последовательно повсюду, потому что это было то, что мне пришлось исправить, чтобы сборка работала.

Тем не менее, могут быть лежащие в основе «но» и «кусочки», которых мне никогда не приходилось касаться, которые используют «обычные» потоки ...

Может быть, кто-то еще, кто знает больше об общей реализации, может вмешаться? @janvorli ?

Это решает проблему для меня:

[furt<strong i="6">@daemon</strong> ~]$ LD_PRELOAD=/usr/lib/libpthread.so ./dotnet-3.x/dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview-010021
 Commit:    d5c97b7c2a

Runtime Environment:
 OS Name:     FreeBSD
 OS Version:  12
 OS Platform: FreeBSD
 RID:         freebsd-x64
 Base Path:   /usr/home/furt/dotnet-3.x/sdk/3.0.100-preview-010021/

Host (useful for support):
  Version: 3.0.0-preview-27218-01
  Commit:  d40b87f29d

.NET Core SDKs installed:
  3.0.100-preview-010021 [/usr/home/furt/dotnet-3.x/sdk]

.NET Core runtimes installed:
  Microsoft.NETCore.App 3.0.0-preview-27218-01 [/usr/home/furt/dotnet-3.x/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Я не проводил никаких обширных тестов, но, по крайней мере, я могу снова выполнить dotnet .

Хорошо, я вижу, что исполняемый файл dotnet не связан с pthreads для других систем, кроме Linux.
https://github.com/dotnet/core-setup/blob/2ef0b64810530961f492c33d37fc7509128e0a9b/src/corehost/cli/exe.cmake#L59 -L61

Означает ли это, что ответ на этот вопрос так же прост, как кажется? Т.е. все так просто? https://github.com/josteink/core-setup/commit/25657ba2e181cce401acd7f4bf9d27a08a668470

Если так, я с радостью сделаю это пиаром.

Да, я так думаю. Я ждал подтверждения от @joperator .
Не уверен, нужен ли нам также "dl", но это можно решить, отправив PR

Верно. Виноват. Так что больше похоже на это: https://github.com/josteink/core-setup/commit/a08f38e25a98c25f59c8ed8c8567a0cb08b1c1c6

Я создал для этого пиар. Сообщите мне, нужны ли какие-либо поправки: https://github.com/dotnet/core-setup/pull/5072

Верно. Виноват. Так что больше похоже на это: josteink / core-setup @ a08f38e

Я создал для этого пиар. Дайте мне знать, если что-то нужно исправить: dotnet / core-setup # 5072

Просто к сведению, кажется, это уже исправлено в базовой системе: https://reviews.freebsd.org/D18988

Похоже, основная проблема в dotnet / coreclr # 22124 исправлена ​​@wfurt.
У меня проблема только при попытке опубликовать автономное приложение на FreeBSD 12.0.

Официальные пакеты NuGet freebsd-x64 были удалены с .NET Core 3.0 Preview 2, и с тех пор мы не могли публиковать приложения для FreeBSD. Есть ли планы снова включить их в версии 3.0?

К сожалению, нам пришлось отменить приоритетность появления FreeBSD (из-за различных причин и трудностей со сквозной поддержкой Azure), и это не будет приоритетом в .NET Core 3.0.
Мы хотели бы, чтобы он оставался полуработающим в том состоянии, в котором он находится сейчас, но у нас сейчас не так много времени, чтобы инвестировать :(.

@karelz Спасибо за ваш ответ, и я понимаю приоритетную работу .NET Core 3.0. Тогда я сосредоточусь на создании своих приложений с эмуляцией FreeBSD Linux. :)

@ hjc4869 Или можете попробовать моно. IIRC, он будет поддерживать .NET Standard 3.0

Я планирую попробовать еще раз, но, как упомянул @karelz, это не приоритет для 3.0.

@newsash Mono - для меня приемлемый вариант. Однако мне было трудно собрать мой проект с моно-целями, добавленными в существующие файлы csproj .NET Core.

На машине с Linux я попытался добавить net472 в TargetFrameworks и установить переменную FrameworkPathOverride, но это не сработало. Если я использую API, который реализован как в моно, так и в .NET Core, но не в .NET Framework, он не сможет построить с моно. Кроме того, хотя mono поддерживает .NET Standard 2.1, я все еще не мог добавить ссылку на библиотеки .NET Standard 2.1 в csproj net472.

Должен ли я добавить отдельный csproj и использовать mono msbuild вместо инструментов dotnet, или у вас есть какие-либо предложения по проблеме?

Небольшое замечание.

Поскольку mono вот-вот будет поглощен .NET 5, согласно недавнему объявлению [1], обеспечение достойной поддержки FreeBSD стало неотложной задачей.

Доказано, что Mono имеет действительно хорошую кроссплатформенную поддержку и может быть без проблем собран из портов FreeBSD. Многие магазины загружают свои .net-файлы на FreeBSD, поскольку эта ОС имеет множество уникальных функций. Пока что mono восполняет этот пробел, но с .NET 5 кажется вероятным, что в ближайшем будущем mono будет объединено с NET 5, и сообщество FreeBSD будет полностью отрезано от экосистемы .NET.

Dotnet должна получить зрелую поддержку FreeBSD задолго до того, как это произойдет.

Я думаю, что Microsoft должна официально поддержать FreeBSD на данном этапе и обеспечить сборку всех инструментов dotnet на этой платформе.

@jasonpugsley собрал инструкции https://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSD, а @joperator пытается заставить работать исходную сборку https: // github. com / dotnet / исходный-сборка / вопросы / 1139

У нас есть последние ~ 30 неудачных тестов для corefx.

System.Diagnostics.Tests.ProcessTests.TestPeakWorkingSet64
System.Diagnostics.Tests.ProcessTests.TestPrivateMemorySize
System.Diagnostics.Tests.ProcessTests.Kill_ExitedNonChildProcess_DoesNotThrow(killTree: True)
System.Diagnostics.Tests.ProcessTests.TotalProcessorTime_PerformLoop_TotalProcessorTimeValid
System.Diagnostics.Tests.ProcessTests.Kill_EntireProcessTree_True_EntireTreeTerminated
System.Diagnostics.Tests.ProcessTests.TestPeakVirtualMemorySize
System.Diagnostics.Tests.ProcessTests.ProcessNameMatchesScriptName
System.Diagnostics.Tests.ProcessTests.TestPrivateMemorySize64
System.Diagnostics.Tests.ProcessTests.LongProcessNamesAreSupported
System.Diagnostics.Tests.ProcessTests.TestPeakWorkingSet
System.Diagnostics.Tests.ProcessTests.TestPeakVirtualMemorySize64
System.Diagnostics.Tests.ProcessTests.Kill_ExitedChildProcess_DoesNotThrow(killTree: True)
System.Diagnostics.Tests.ProcessTests.Kill_EntireProcessTree_True_CalledOnTreeContainingCallingProcess_ThrowsInvalidOperationException
System.IO.Tests.DirectoryInfo_MoveTo.MoveDirectory_FailToMoveLowerCaseDirectoryWhenUpperCaseDirectoryExists
System.IO.Tests.FileInfo_Exists.LockedFileExists
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 0, firstLength: 10, secondPosition: 1, secondLength: 2)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 3, secondLength: 5)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 3, secondLength: 4)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 4, secondLength: 5)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 2, secondLength: 6)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 2, secondLength: 4)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 4, secondLength: 6)
System.IO.Tests.Directory_Move.MoveDirectory_FailToMoveLowerCaseDirectoryWhenUpperCaseDirectoryExists
System.Net.NameResolution.Tests.GetHostEntryTest.Dns_GetHostEntry_HostString_Ok(hostName: \"\")
System.Net.NameResolution.Tests.GetHostEntryTest.Dns_GetHostEntryAsync_HostString_Ok(hostName: \"\")
System.Net.NameResolution.Tests.GetHostByNameTest.DnsObsoleteBeginEndGetHostByName_EmptyString_ReturnsHostName
System.Net.NameResolution.Tests.GetHostByNameTest.DnsObsoleteGetHostByName_EmptyString_ReturnsHostName
System.Net.NetworkInformation.Tests.PingTest.SendPingAsyncWithIPAddressAndTimeoutAndBufferAndPingOptions_Unix(addressFamily: InterNetwork)
System.Net.NetworkInformation.Tests.PingTest.SendPingWithIPAddressAndTimeoutAndBufferAndPingOptions_Unix(addressFamily: InterNetwork)
System.Net.Sockets.Tests.DualModeAcceptAsync.AcceptAsyncV4BoundToSpecificV4_Success
System.Tests.AppDomainTests.MonitoringIsEnabled
System.Tests.GCExtendedTests.GetGCMemoryInfo

@ am11 смотрит на System.Diagnostics.Tests.ProcessTests, поэтому неудачные тесты блокировки кажутся самым большим оставшимся пробелом. Было бы здорово, если бы кто-нибудь мог посмотреть dotnet / corefx # 30899.

Просто интересно, есть ли обновления по этому поводу или он заброшен?

@elfalem , в наши дни https://github.com/dotnet/dotnet-buildtools-prereqs-docker/ , в котором установлены все предварительные требования. Мы можем использовать один и тот же контейнер докеров для публикации пакета времени выполнения (в основном tar.gz) локально или на удаленном компьютере. например, мы можем настроить действие GitHub в одной из веток вилки, например: https://github.com/am11/runtime/blob/feature/freebsd/ci/.github/workflows/main.yml , который загружает артефакты в выпуски GitHub по тегу push https://github.com/am11/runtime/releases/tag/6.0.0-dev.freebsd.1. Архив dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz в этом случае имеет достаточно бит, чтобы просто запустить опубликованное приложение dotnet (из другой системы linux / mac, в которой есть dotnet SDK). Я протестировал его, создав новую виртуальную машину 12.2 (vagrant), извлек и скопировал опубликованное приложение с Mac на виртуальную машину, это сработало:

#!/usr/bin/env tcsh

$ sudo pkg install libunwind icu libinotify

$ fetch https://github.com/am11/runtime/releases/download/6.0.0-dev.freebsd.1/dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz
$ mkdir ~/.dotnet
$ tar xzf dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz -C ~/.dotnet

$ set PATH=(~/.dotnet:$PATH)
$ setenv PATH "$PATH"

$ dotnet /vagrant/MyPublishedApp.dll
Hello World!

Я думаю, что @Thefrank в какой-то момент

Просто интересно, есть ли обновления по этому поводу или он заброшен?

вы можете посмотреть https://github.com/dotnet/source-build/issues/1139
Я не пробовал в последнее время, так как жду окончательную версию dotNET5, но, по состоянию на несколько месяцев назад, среда выполнения FreeBSD могла быть построена только как кросс-компиляция в Linux. ASPNet и SDK также требовали кросс-компиляции Linux, но создавались только в том случае, если звезды совпадали (обновления аркад или какой-либо другой автоматизированный бот не нарушал зависимости)

edit: и @ am11 опубликовал лучшую запись, пока я печатал ночную прогулку. читай это, а не мое
edit2: забыл о пунктуации, и похоже, что final был выпущен 2 дня назад. Думаю, мне нужно поработать над этим или что-то в этом роде

Помимо всего вышеперечисленного, я создал проект FreeBSD в https://github.com/dotnet/runtimelab/, и я медленно продвигаюсь в создании и публикации пакетов. Цель состоит в том, чтобы собрать и опубликовать достаточно, чтобы приложение могло работать на FreeBSD и иметь начальное число для сборки исходного кода.

Думал написать быстрое обновление. Я наконец-то выровнял все планеты для сборки 5.0.0 RTM на FreeBSD. Я не успевал с Preview3, и потребовалось время (и _много_ попыток сборки), чтобы найти правильную комбинацию совместимых сборок, чтобы получить успешную версию 5.0.
Мне удалось собрать PowerShell 7.1.0 с удивительно небольшим количеством хаков, он работает, хотя я не тестировал его полностью, но похоже, что это хороший тест SDK.
Я только что построил AspNetCore, но еще не тестировал его.

$ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.100
 Commit:    5044b93829

Runtime Environment:
 OS Name:     FreeBSD
 OS Version:  11
 OS Platform: FreeBSD
 RID:         freebsd.11-x64
 Base Path:   /tmp/rtm/sdk/5.0.100/

Host (useful for support):
  Version: 5.0.0
  Commit:  cf258a14b7

.NET SDKs installed:
  5.0.100 [/tmp/rtm/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.0 [/tmp/rtm/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.0 [/tmp/rtm/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download
$ dotnet new console
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on /tmp/test/test.csproj...
  Determining projects to restore...
  Restored /tmp/test/test.csproj (in 106 ms).
Restore succeeded.

$ dotnet run
Hello World!
$

$ LANG=en-US ./pwsh
PowerShell 7.1.0
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

PS /tmp/powershell> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.1.0
PSEdition                      Core
GitCommitId                    7.1.0
OS                             FreeBSD 11.4-RELEASE FreeBSD 11.4-RELEASE #0 r362094: Fri Jun 12 18:27:15 UTC 2020     [email protected]:/usr/obj/usr/src/sys/GE…
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

PS /tmp/powershell> Get-Host

Name             : ConsoleHost
Version          : 7.1.0
InstanceId       : fa711f95-926c-47e4-9e0c-dff0f518f825
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : en-US
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace


PS /tmp/powershell>

Единственная проблема, связанная с выполнением этой работы вручную (т.е. вне системы CI), - это проблема, вызванная критическими изменениями, требующими, чтобы конкретная сборка была доступна для использования в следующей сборке. Это случается не часто, но для поиска правильной фиксации требуется много проб и ошибок. Перекрестная сборка linux в системе CI должна исправить это, но я еще не смотрел на это. Тем не менее, приятно знать, что я могу создать полный SDK, а затем использовать этот SDK для создания чего-то еще.

russellh<strong i="5">@freebird</strong>:/www/winlua_net/htdocs/downloads$ pkg search dotnet
linux-dotnet-cli-2.0.7         Cross-platform .NET implementation
linux-dotnet-runtime-2.0.7     Cross-platform .NET implementation
linux-dotnet-sdk-2.1.201       Cross-platform .NET implementation (Software Development Kit)
linux-dotnet10-runtime-1.0.11  Cross-platform .NET implementation
linux-dotnet10-sdk-1.1.9       Cross-platform .NET implementation (Software Development Kit)
linux-dotnet11-runtime-1.1.8   Cross-platform .NET implementation

Это хороший прогресс @jasonpugsley. Я пытаюсь найти лучший ответ для сборки, но за последние несколько месяцев мне не удалось выделить сколько-нибудь приличный отрезок времени; (
PowerShell огорчил вас из-за terminfo или вы скопировали определение терминала откуда-то еще?

Я взял определение терминала с моего Mac, откуда я был ssh'd.

@jasonpugsley, ты намного опередил меня. сборка ядра и sdk из linux cross freebsd. работать нормально из-за ограниченного тестирования, которое я сделал. ни среда выполнения, ни кроссбилты sdk не могут строить сами на freebsd (linux и freebsd используют llvm9 и clang9).
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0
Плохо ткните в него еще немного, если у меня будет больше времени в эти выходные, а также посмотрю, смогу ли я хотя бы получить aspnetcore, построенный на Linux для freebsd

@Thefrank , ты имеешь в виду:

$ ROOTFS_ENV="ROOTFS_DIR=/crossrootfs/x64"
$ DOTNET_DOCKER_TAG="mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-18.04-cross-freebsd-11-20201109180854-f13d79e"
$ docker run -e $ROOTFS_ENV -v $(pwd):/runtime $DOTNET_DOCKER_TAG /runtime/build.sh -c Release -cross -os freebsd

происходит сбой или двоичные файлы в artifacts/packages/Release/Shipping/dotnet-runtime-5.0.0-dev-freebsd-x64.tar.gz не выполняются?
Если вы пытаетесь кросскомпилировать SDK 5x на Ubuntu 18 или 20, вы можете применить этот патч https://github.com/dotnet/sdk/commit/80e42f16422352f725d78be72071781d8365a238 (он находится в основной ветке).

Мне действительно нужно перестать публиковать посты в полусне.
Сборка среды выполнения и SDK в Linux завершена.
Эти двоичные файлы запускаются на freebsd (dotnet --info, новая консоль и запускается)
Эти двоичные файлы не могут создать среду выполнения или SDK из исходного кода на freebsd.

Ах хорошо. Я не пробовал создавать двоичные файлы stage0, чтобы перестроить среду выполнения на FreeBSD как HostOS.

ld: ошибка: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim. экспорт: 1 : неизвестно директива: V1.0

Возможно, стоит сообщить об этой проблеме отдельно. Вероятно, есть несколько способов исправить это, но имеет ли этот патч какое-либо значение:

--- a/eng/native/functions.cmake
+++ b/eng/native/functions.cmake
@@ -211,7 +211,7 @@ function(generate_exports_file)
   list(GET INPUT_LIST -1 outputFilename)
   list(REMOVE_AT INPUT_LIST -1)

-  if(CMAKE_SYSTEM_NAME STREQUAL Darwin)
+  if(CMAKE_SYSTEM_NAME STREQUAL Darwin OR CLR_CMAKE_HOST_FREEBSD)
     set(AWK_SCRIPT generateexportedsymbols.awk)
   else()
     set(AWK_SCRIPT generateversionscript.awk)
@@ -229,7 +229,7 @@ endfunction()

 function(generate_exports_file_prefix inputFilename outputFilename prefix)

-  if(CMAKE_SYSTEM_NAME STREQUAL Darwin)
+  if(CMAKE_SYSTEM_NAME STREQUAL Darwin OR CLR_CMAKE_HOST_FREEBSD)
     set(AWK_SCRIPT generateexportedsymbols.awk)
   else()
     set(AWK_SCRIPT generateversionscript.awk)

этот патч имеет значение

Я ожидал, что FreeBSD последует за Linux в том, что касается сценариев символьной версии, а не за Дарвином. ИМО, более вероятно, что проблема в том, что в generateversionscript.awk есть что-то специфичное для GNU-awk

патч изменил ошибку:
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: _CreateProcessForLaunch
если проблема с версией awk:

awk --version
awk version 20121220 (FreeBSD)

Если легко поэкспериментировать, можете ли вы попробовать установить пакет gawk и изменить вызов в файлах CMake на gawk?

откатил патч. установлен gawk pkg.
слишком ленив, чтобы выяснить, как скрипт build.sh передает аргументы cmake, так как это не сразу имеет смысл, поэтому я просто сделал символическую ссылку gawk-> awk.
та же исходная ошибка
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0

Позднее редактирование: похоже, что двоичные файлы в Linux не были правильно собраны:

# ./dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.101-servicing.20605.0
 Commit:    c3a779b104

Runtime Environment:
 OS Name:     FreeBSD
 OS Version:  12
 OS Platform: FreeBSD
 RID:         osx-x64
 Base Path:   /root/runtime/.dotnet/sdk/5.0.100/

Host (useful for support):
  Version: 5.0.1
  Commit:  2ee13ec8e5

.NET SDKs installed:
  5.0.100 [/root/runtime/.dotnet/sdk]

.NET runtimes installed:
  Microsoft.NETCore.App 5.0.1 [/root/runtime/.dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

в основном RID: osx-x64 может вызывать некоторые проблемы

в основном RID: osx-x64 может вызывать некоторые проблемы

Этот RID отображается SDK после некоторых разрешений поддерживаемых и неподдерживаемых платформ. Это практически не влияет на выполнение приложения. Настоящий RID, обнаруженный средой выполнения, является правильным, в противном случае приложения (например, dotnet(1) ) не будут выполняться должным образом.
c# using System; using System.Runtime.InteropServices; class Program { static void Main() => Console.WriteLine("Real RID: {0}", RuntimeInformation.RuntimeIdentifier); }
печатает Real RID: freebsd.12-x64 на моей коробке.

Открыт №45663 для отслеживания проблемы с ld. Я тоже умел воспроизводить.

@Thefrank относительно ошибки ld, попробуйте следующее:

diff --git a/eng/native/configurecompiler.cmake b/eng/native/configurecompiler.cmake
index 006a180fa0a..2a270572532 100644
--- a/eng/native/configurecompiler.cmake
+++ b/eng/native/configurecompiler.cmake
@@ -594,7 +594,7 @@ else (CLR_CMAKE_HOST_WIN32)
         ERROR_QUIET
         OUTPUT_VARIABLE ldVersionOutput)

-    if("${ldVersionOutput}" MATCHES "GNU ld" OR "${ldVersionOutput}" MATCHES "GNU gold")
+    if("${ldVersionOutput}" MATCHES "GNU ld" OR "${ldVersionOutput}" MATCHES "GNU gold" OR "${ldVersionOutput}" MATCHES "LLD")
         set(LD_GNU 1)
     elseif("${ldVersionOutput}" MATCHES "Solaris Link")
         set(LD_SOLARIS 1)

Это активирует предложение else в eng/native/functions.cmake здесь:

function(set_exports_linker_option exports_filename)
    if(LD_GNU OR LD_SOLARIS)
        # Add linker exports file option
        if(LD_SOLARIS)
            set(EXPORTS_LINKER_OPTION -Wl,-M,${exports_filename} PARENT_SCOPE)
        else()
            set(EXPORTS_LINKER_OPTION -Wl,--version-script=${exports_filename} PARENT_SCOPE)
        endif()
    elseif(LD_OSX)
        # Add linker exports file option
        set(EXPORTS_LINKER_OPTION -Wl,-exported_symbols_list,${exports_filename} PARENT_SCOPE)
    endif()
endfunction()

Честно говоря, я не эксперт по компоновщикам, поэтому, пока это работает, я не стал углубляться, чтобы увидеть, что на самом деле требуется / канонично для clang во FreeBSD.

Ага, снова возникает проблема с пользовательским агентом компоновщика. Строка версии LLD включает (compatible with GNU linkers) в попытке пойти по пути GNU ld тестов configure, но явно недостаточно умна для этого случая :)

Сопоставление по LLD выглядит здесь хорошо, даже если флаг LD_GNU теперь несколько неверно назван.

Да, нужно еще поработать. Название флага теперь сбивает с толку. Пожалуйста, не пытайтесь делать это как есть.

От: Эд Масте [email protected]
Отправлено: понедельник, 7 декабря 2020 г., 10:26:48
Кому: dotnet / runtime [email protected]
Копия: Джейсон Пагсли [email protected] ; Упомяните упоминание@noreply.github.com
Тема: Re: [dotnet / runtime] Поддержка FreeBSD (# 14537)

Ага, снова возникает проблема с пользовательским агентом компоновщика. Строка версии LLD включает (совместимую с компоновщиками GNU) в попытке пройти по пути GNU ld тестов configure, но явно недостаточно умна для этого случая :)

Сопоставление по LLD выглядит здесь хорошо, даже если флаг LD_GNU теперь несколько неверно назван.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/dotnet/runtime/issues/14537#issuecomment-739583816 или отмените подписку https://github.com/notifications/unsubscribe-auth/AECFDEXKTDFRAX4ZEE6VXZTSTQHLRANTS .

Я решил использовать https://github.com/dotnet/runtime/pull/45664
Clr наращивается до подмножества Clr.Tools, а затем завершается неудачно с

/root/runtime/.dotnet/sdk/5.0.100/Microsoft.Common.CurrentVersion.targets(4818,5): error MSB3030: Could not copy the file "/root/runtime/artifacts/bin/coreclr/FreeBSD.x64.Release/libjitinterface" because it was not found. [/root/runtime/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj]
/root/runtime/.dotnet/sdk/5.0.100/Microsoft.Common.CurrentVersion.targets(4818,5): error MSB3030: Could not copy the file "/root/runtime/artifacts/bin/coreclr/FreeBSD.x64.Release/libclrjit" because it was not found. [/root/runtime/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj]

подмножество «моно» и подмножество «библиотеки» без ошибок

@Thefrank Это вторая часть этого различия, которую вам нужно исправить:

diff --git a/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj b/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj
index 2de5f568214..87242a728f0 100644
--- a/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj
+++ b/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj
@@ -12,7 +12,7 @@
     <OutputPath>$(BinDir)/crossgen2</OutputPath>
     <GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles>
     <EnableDefaultEmbeddedResourceItems>false</EnableDefaultEmbeddedResourceItems>
-    <RuntimeIdentifiers>linux-x64;linux-musl-x64;win-x64</RuntimeIdentifiers>
+    <RuntimeIdentifiers>linux-x64;linux-musl-x64;win-x64;freebsd-x64</RuntimeIdentifiers>
     <Configurations>Debug;Release;Checked</Configurations>
   </PropertyGroup>

@@ -53,6 +53,7 @@
     <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('WINDOWS'))">.dll</LibraryNameExtension>
     <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('LINUX'))">.so</LibraryNameExtension>
     <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('OSX'))">.dylib</LibraryNameExtension>
+    <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('FREEBSD'))">.so</LibraryNameExtension>

     <JitInterfaceLibraryName>$(LibraryNamePrefix)jitinterface$(LibraryNameExtension)</JitInterfaceLibraryName>
   </PropertyGroup>

Лучше было бы добавить в строку LINUX как ИЛИ в условии.

@jasonpugsley, который сделал
/root/runtime/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj : error NU1101: Unable to find package Microsoft.AspNetCore.App.Runtime.freebsd-x64. No packages exist with this id in source(s):
Я знал, что забыл что-то сделать несколько дней назад! Это должно быть интересно

изменить: без кроссгена (также известный как вторая половина)

./build.sh -c Release -bl:buildlog.binlog

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:12:05.56

отредактировать последнее изменение в этом сообщении Клянусь:
Я знаю, что тесты могут занять некоторое время, и он говорит о длительном тестировании, но это выходит из-под контроля для одного теста
System.Net.HttpListener.Tests: [Long Running Test] 'System.Net.Tests.HttpListenerResponseTests.AddLongHeader_DoesNotThrow', Elapsed: 00:36:20

убил тест после ожидания 2 часа другие тесты все еще имели сбои

/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'Microsoft.Extensions.Hosting.Unit.Tests'. Please check /root/runtime/artifacts/bin/Microsoft.Extensions.Hosting.Unit.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/Microsoft.Extensions.Hosting/tests/UnitTests/Microsoft.Extensions.Hosting.Unit.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.NameResolution.Functional.Tests'. Please check /root/runtime/artifacts/bin/System.Net.NameResolution.Functional.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.NameResolution/tests/FunctionalTests/System.Net.NameResolution.Functional.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.NetworkInformation.Functional.Tests'. Please check /root/runtime/artifacts/bin/System.Net.NetworkInformation.Functional.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.NetworkInformation/tests/FunctionalTests/System.Net.NetworkInformation.Functional.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'Microsoft.VisualBasic.Core.Tests'. Please check /root/runtime/artifacts/bin/Microsoft.VisualBasic.Core.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/Microsoft.VisualBasic.Core/tests/Microsoft.VisualBasic.Core.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Console.Tests'. Please check /root/runtime/artifacts/bin/System.Console.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Console/tests/System.Console.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Runtime.Extensions.Tests'. Please check /root/runtime/artifacts/bin/System.Runtime.Extensions.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Runtime.Extensions/tests/System.Runtime.Extensions.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Sockets.Tests'. Please check /root/runtime/artifacts/bin/System.Net.Sockets.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.Sockets/tests/FunctionalTests/System.Net.Sockets.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.IO.FileSystem.Tests'. Please check /root/runtime/artifacts/bin/System.IO.FileSystem.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.IO.FileSystem/tests/System.IO.FileSystem.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Ping.Functional.Tests'. Please check /root/runtime/artifacts/bin/System.Net.Ping.Functional.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.Ping/tests/FunctionalTests/System.Net.Ping.Functional.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Requests.Tests'. [/root/runtime/src/libraries/System.Net.Requests/tests/System.Net.Requests.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.WebSockets.Client.Tests'. [/root/runtime/src/libraries/System.Net.WebSockets.Client/tests/System.Net.WebSockets.Client.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Security.Cryptography.X509Certificates.Tests'. Please check /root/runtime/artifacts/bin/System.Security.Cryptography.X509Certificates.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Security.Cryptography.X509Certificates/tests/System.Security.Cryptography.X509Certificates.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.WebClient.Tests'. [/root/runtime/src/libraries/System.Net.WebClient/tests/System.Net.WebClient.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Security.Tests'. Please check /root/runtime/artifacts/bin/System.Net.Security.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.Security/tests/FunctionalTests/System.Net.Security.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Diagnostics.Process.Tests'. Please check /root/runtime/artifacts/bin/System.Diagnostics.Process.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Diagnostics.Process/tests/System.Diagnostics.Process.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Security.Cryptography.Xml.Tests'. [/root/runtime/src/libraries/System.Security.Cryptography.Xml/tests/System.Security.Cryptography.Xml.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Runtime.Tests'. Please check /root/runtime/artifacts/bin/System.Runtime.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Runtime/tests/System.Runtime.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.HttpListener.Tests'. [/root/runtime/src/libraries/System.Net.HttpListener/tests/System.Net.HttpListener.Tests.csproj]
    0 Warning(s)
    18 Error(s)

Time Elapsed 02:11:29.07
Build failed (exit code '1').