сс, gcc, g++

Ну и зачем ты его собрал? https://packages.debian.org/experimental/gcc

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

по любому не правильно размазалась по системе gcc. помогите исправить

Перезагрузись, перелогинься или запусти новый шел. На выбор.

Если это для сброса хеша, то можно просто hash -r.

перезагружался....

gcc -v
gcc-9.1.0

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

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

Заявление о том, что у тебя не получается, это не вопрос. Опять решил нытьё развести на несколько страниц?

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

вопрос: почему установленный из репозитория gcc и g++ видны всем программам , а собранный из source не виден

gcc -v
gcc-9.1.0
не видит и ругается на <iostream>

У тебя прога на c++, а ты её сишным компилятором пытаешься скомпилять. Дальше надеюсь сам догадаешься?

не,не.... я же писал что не видит g++ . я делал

>c.cpp
nano 
#include <iostream>
int main(){

std::cout << "hi";
return 0;
}
g++ c.cpp
./a.out

при соборке gcc и с++ собирается и устанавливается. но его сейчас не видят почему -то. причина примерно понятна: неправильно разнес. но что сделать теперь?

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

но что сделать теперь?

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

я хотел чтобы make install сам разнес по директориям исполняемые файлы отдельно, библиотеки отдельно.... он разнес, но видимо как -то не правильно. я же правильно указал?

./configure --bindir=/usr/bin  --/libdir=/usr/lib?

Эти опции ты откуда взял? Там написано, что они делают?

Обычно префикс устанавливается опцией prefix. Попробуй --prefix=/usr.

ну это не точно.

скажите,вот если бы вы скомпилили gcc и решили бы сделать так,чтобы при make install все библиотеки и исполняемые файлы заняли свои места в системе. как бы Вы сделали? какие изменения и куда бы Вы внесли?

как бы Вы сделали?

Начал бы читать документацию.

решили бы сделать так,чтобы при make install

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

как тогда сделать,чтобы make install установил бинарники и библиотеки в нужные и видные места? напишите уже пример ,да закроем эту тему. уже второй месяц спрашиваю и нет внятного ответа. как надо задать ./configure чтобы создался makefile который распихает все по правильным директориям? ну Вы указали что ./configure --prefix=/usr а что дальше? он засунет и исполняемые и библиотеки в usr. но надо же чтобы библиотеки были в /usr/lib а бинарники в /usr/bin но у нас то --prefix=/usr ,если записать /---prefix=/usr/bin то тут будут и бинарники и библиотеки,а нам это не надо, если --prefix=/usr/lib то сюда попадут и бинарники и библиотеки ,а должны быть лишь библиотеки... как делать то?

но у нас то --prefix=/usr

prefix - это корень. Всё будет расфасовано по подкаталогам как полагается. А чтобы не засорять систему, можно просто указать --prefix=/opt/gcc-9. А потом после установки: export LD_LIBRARY_PATH=/opt/gcc-9/lib:$LD_LIBRARY_PATH и export PATH=/opt/gcc-9/bin:$PATH.

Для начала я бы не стал экспериментировать в рабочей системе с таким глобальными вещами как основной компилятор. Если ты установишь не ту версию, которая протестирована ментейнерами, то у тебя могут начаться проблемы, например со сборкой dkms модулей.

В дистрибутивах могут быть механизмы установки нескольких компиляторов разных версий и переключений между ними. Например, в debian-based дистрибутивах это alternatives (https://wiki.debian.org/DebianAlternatives). Заменяя бинарники таким варварским способом в /usr/bin ты его ломаешь.

По хорошему, ты не должен трогать ничего, что стоит в /usr/bin, /usr/lib и т.д. Для этого есть /usr/local/bin, /usr/local/lib и т.д. (см https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standard). /usr/local/… имеет более высокий приоритет при поиске бинарников и ты не будешь трогать файлы в директориях, которые контролируются пакетным менеджером. + тебе будет легко их грохнуть и не затереть системные файлы.

В 99% make install по умолчанию (без принудительного указания —prefix и других подобных флагов) считает префиксом именно /usr/local и будет соблюдать остальные части путей (т.е. бинарники будет ставить в /usr/local/bin, либы в /usr/local/lib и lib64 и т.д.)

Т.е. тебе нужно было просто вызвать configure без параметров, а затем make install и все было бы хорошо. А сейчас у тебя каша.

Подобными вещами лучше экспериментировать в докере:

docker run --rm -ti ubuntu:18.04 bash

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

а я что не делал configure без prefix и прочих параметров. делал конечно же. и все устанавливалось в /usr/local/bin в один каталог. вообще все. каша была там.

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

то есть ,если я укажу

 ./configure --prefix=/usr/local 

уже второй месяц спрашиваю и нет внятного ответа

В теме уже есть все ответы.

ну так уточните пожалуйста, если

./configure --prefix=/usr/local