>>177573
Зачем гасить иксы, если это не сервер? Если сервер, то зачем запускать? Гугли в сторону драйверов фреймбуфера и VESA, они работают по умолчанию, когда других нет.

>>177573
А вообще вот, первые же ссылки на подобные проблемы с решением
https://www.google.ru/search?q=freebsd+after+xorg+screen

>>177575>>177576
Это я уже видел. Меня интересует другое - я устанавливаю ОС, обновляю pkg, на голую ОС устанавливаю иксы - всё работает нормально. Переустанавливаю ОС с форматированием диска и точно теми же параметрами, как и в прошлый раз, точно так же ставлю иксы - на этот раз они через жопу. И так 50:50. Где логика? Хард WD Blue исправный, без бедов, наработка очень небольшая (используется для экспериментов), так что на ошибки на нём грешить не буду.

>>177890
Скажу банальность, но в логах иксов нет ничего подозрительного?

>>177891
Сейчас иксы работают нормально, так что ничего не могу сказать. Завтра достану ещё один диск - полудохлый шанцунг на 160 ГБ с первой сатой, попробую поставить систему туда - тогда и посмотрю.

>>177573

Хм, внезапно, а переключение консоли на newcons не помогает?

>>178293
Пока даже не пробовал доводить систему до такой хрени. К тому же, сейчас пока снёс систему, поставил начисто и пытаюсь собрать OpenJDK 8 (не собирается, если в make.conf явно указать CC и CXX - причём, не зависит от компилятора - хоть я напишу туда clang37/clang++37, хоть gcc5/g++5, по умолчанию же он компилирует дефолтным Clang 3.4 - не думаю, что у ПО, скомпилированного старьём, будет хорошая производительность).

>>178295
Шланг сам по себе не особо, какую версию не возьми. Да и OpenJDK заточен под сборку GCC, ЕМНИП

>>178308
Так один хрен, сборка GCC даёт тот же результат.
Экспериментальным путём установил, что для нормальной сборки нужно убрать явную установку CXX, а также -O2 из CFLAGS. Но в таком случае меня интересуют две вещи:

1. Чем будут собираться файлы с кодом на C++, если я не пропишу CXX. Тем компилятором, который шёл из коробки (т.е., Clang 3.4)?
2. Что будет с оптимизацией, если я не пропишу -O2. Он будет собираться без оптимизации (как при -O0)?

>>178309
Так почему не собирается-то? "Не собирается" - слишком широкое описание проблемы. Ты хотя бы строчки из лога сборки или вывод сюда привел.
На твой первый вопрос я ХЗ что ответить, потому что с системой портов фряхи имел дело давно (лет эдак 8 назад) и уже не помню, что там к чему. Ответ на второй вопрос дает man gcc:

> Without any optimization option, the compiler's goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent: if you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the function and get exactly the results you expect from the source code.

У шланга, ЕМНИП, что-то аналогичное, хотя там с документацией все печально и указать точную цитату я не смогу.

В общем, отчитываюсь о решении проблемы с компиляцией OpenJDK.
Сборка этой штуки всегда идёт через задницу я уже не говорю о том, что нужно ставить переменную среду MAKE_JOBS_UNSAFE=yes, выкидывается большое количество предупреждений о неявных преобразованиях, неиспользуемых переменных и прочем. Всё это никак не зависит от используемого компилятора.
Так вот, чтобы поставить нужные флаги компиляции, во избежание ошибок, их стоит закомментировать в /etc/make.conf и прописать в виде переменных сред и собирать порт от рута (причём, не через su, а именно зайдя под рутом). То есть, если я пропишу в /etc/make.conf CFLAGS=-march=core2 -mtune=core2 -O2 -pipe, то будет ошибка компиляции (уже не помню, какая, снёс систему и ставлю начисто), а вот если выполнить setenv CFLAGS '-march=core2 -mtune=core2 -O2 -pipe', то сборка пойдёт нормально с этими флагами (собирал как Clang 3.8, так и GCC 5.3.0). Логику не особо понимаю и искать её у меня сейчас особого желания нет. Вот такой костыль.
Касательно CXX - конкретно для OpenJDK его указывать не обязательно - судя по выхлопу мейка, в качестве него подхватывается CC. А вот для многих других портов (в том числе, для зависимостей) будет использоваться дефолтный компилятор.
Ещё интересное наблюдение - в некоторых моментах при сборке OpenJDK (но не везде - в большинстве случаев, будет использоваться то, что указано пользователем и ничего, если ничего им явно не указано) явно указан параметр -O2 (видимо, на случай сборки с -O3 или -Ofast, так как с такими параметрами собрать этот код невозможно) или даже -Os (вот это я не особо понимаю - у меня много места на диске и я не хочу жертвовать производительностью в угоду размеру, а тот, у кого этого места мало, сам при компиляции явно укажет -Os).
Проблема с иксами снова пока не появлялась.

>>178332
Кстати, у меня к тебе все-таки один вопрос будет. Почему фряха?

>>178333
Что предлагаешь? Арч?

>>178335
Ну а почему бы и нет?

мимо->>177891-Чии

>>178345
Как-то не горю желанием собирать систему самостоятельно как конструктор. Сложно всё это слишком.

>>178347
Тут должен быть скриншот с LFS и ироничное ыыыыыы

>>178335
Не, арч - это для тех, кому неймется.
>>178347
Ничего сложного. Та же калька, например, по сути просто генту с бинарными репозиториями. Каких-то особых проблем я не наблюдаю, скачал образ и поставил, ничуть не сложнее бубунту. А там уже можно смотреть, что тебе нужно, и ставить отдельно.

Тем временем, ОП докладывает об успешной сборке с первого раза OpenJDK 8 (Снёс систему, решил поставить всё с нуля (всё равно, половина пакетов устанавливалась кое-как и не с первого раза, от удалений, наверняка, много мусора в глубине системы осталось).) вместе со всеми зависимостями с полностью заполненным /etc/make.conf с указанием компилятора, типа процессора, -O3, всех мультимедийных расширений, поддерживаемых моим процессором и -pipe как для Си, так и для C++.
Где логика? При одной установке иксы работают через задницу, переустановлю систему начисто, установлю иксы (действия повторяю точь-в-точь, даже специально записывал) - работают нормально. С джавой то же самое.

>-O2, -O3
>не собирается
>работает через раз
>тех.документация для лохов

админы локалхоста за работой

>>178822
Да, блджад, оно собирается, но собирается через раз и логики, почему сейчас оно собирается, а завтра, если снести систему и поставить начисто, не соберётся.

>>178829 мда
клиника

>>178822>>178845

Нечего винить людей в том, что они надеются на defined-поведение кода. Целые корпорации сами виноваты в том, что O3 не работает.

Код, который не работает в O3, плох.

>>178819

>При одной установке иксы работают через задницу, переустановлю систему начисто, установлю иксы (действия повторяю точь-в-точь, даже специально записывал) - работают нормально. С джавой то же самое.

Хороший повод для багрепорта.

>>178819

>повод для багрепорта

Это я не об О3 говорю (если код не работает с O3, его не исправишь), а про то, что

>не собирается

а потом перечиатл твоё сообщение и понял, что не ты об это писал, а бака >>178822, которая читает мугичкой.

>>178848 в рассылке мамкиных оптимизаторов шлют в сторону, обратную серверу, быстро и решительно. где вообще прописана необходимость трогать cflags?

>>178853

>где вообще прописана необходимость трогать cflags?

Спроси ещё:

>где вообще прописана необходимость писать well-defined-код?

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

Код должен быть well-defined <точка>

То, что девелоперы не тестят код с O3, красноречиво говорит о девелоперах.

>>178859

>То, что девелоперы не тестят код с O3, красноречиво говорит о девелоперах.

Ну, у меня пока что на FreeBSD не было случаев, чтобы не собиралось с -O3.
Написал я это к тому, что оно даже и с -O3 нормально собралось. Вообще без ошибок.
Алсо, пикрелейтед - вот что бывает, если несколько раз подряд сделать make config-recursive - make rmconfig-recursive.

>>178872

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

>>178877
Нет, это значит, что нужно восстановить систему из бекапа целиком, но, поскольку у меня нет ни ленточного накопителя, ни дисков достаточного объёма, на которые можно сбекапить целые разделы, я просто снёс систему и поставил заново.
Похожая хрень имеется и на дебиане - достаточно несколько раз побаловаться apt-get autoremove - и начинаются проблемы.

>>178859
Вообще в O3 традиционно попадают оптимизации, которые не считаются железобетонно надежными и для которых не гарантируется, что они всегда будут отрабатывать корректно, но которые достаточно хорошо протестированы для применения в большинстве случаев. Во времена GCC 3.x O3 вообще был "for brave adventurers", в четвертой ветке дело стабилизировали и совсем уж адовые трюки туда теперь не попадают. Поэтому совет тебе собирать с O2, это включит те оптимизации, которые сами разработчики компилятора считают стабильными (и уж поверь, если такие замшелые консерваторы как девелоперы GCC считают код стабильным - под это дело можно жизнью рисковать).

>>178890

>Вообще в O3 традиционно попадают оптимизации, которые не считаются железобетонно надежными и для которых не гарантируется, что они всегда будут отрабатывать корректно

Это ты сейчас про -Ofast говоришь, а не про -O3.

Разработчики GCC считают O3 вполне стабильным.