Raven's questions

Eu quero fazer uso de uma versão mais recente do GCC. Portanto, compilei o GCC 10 e instalei-o em um diretório não padrão /software/gcc10/. Até agora tudo bem.

No entanto, estou enfrentando problemas quando realmente quero usar esta nova versão do GCC. Modifiquei minha PATHvariável para incluir /software/gcc10/bin/tal que gcc --versionagora confirma que o sistema encontra meu novo compilador GCC 10 (em vez do GCC 8 do meu sistema).

No entanto, quando tento compilar um programa com essa configuração, recebo erros sobre referências indefinidas a std::filesystem, que devem fazer parte do libstdc++ do GCC 10. Minha suposição aqui é que, enquanto estou usando um compilador mais recente, o vinculador ainda deseja vincular o libstdc++ do meu sistema em vez do /software/gcc10/lib64.

Eu tentei mudar LD_LIBRARY_PATHpara incluir o respectivo diretório, mas isso não parece ter nenhum efeito.

Inspecionando a saída da execução gcccom a -vopção, me deparei com a LIBRARY_PATHvariável de ambiente, que de acordo com a documentação do gcc é usada da seguinte forma:

O valor de LIBRARY_PATH é uma lista de diretórios separados por dois pontos, muito parecido com PATH. Quando configurado como um compilador nativo, o GCC tenta os diretórios assim especificados ao procurar arquivos de linker especiais, se não conseguir encontrá-los usando GCC_EXEC_PREFIX. A vinculação usando o GCC também usa esses diretórios ao procurar bibliotecas comuns para a opção -l (mas os diretórios especificados com -L vêm primeiro).

E, de fato: Definir a LIBRARY_PATHvariável de acordo me permite compilar meu programa com sucesso. No entanto, parece que esta é uma solução específica do gcc e não posso deixar de me perguntar se existe uma maneira mais padrão de fazer isso (que, por exemplo, também diria ao clang onde procurar a biblioteca padrão C++ para vincular)?

Ainda melhor seria uma solução que faria com que meu novo compilador GCC 10 sempre usasse o GCC 10 stdlib, enquanto a invocação do compilador GCC 8 do sistema sempre se vincularia aos sistemas GCC 8 stdlib. Existe uma maneira de dizer a um binário de compilador específico que ele possui um stdlib específico que ele deve usar?

Nas configurações do KDE, posso definir meu idioma e formatos para diferentes localidades. Isso me permite escolher entre um monte deles. Nesta lista também está a localidade en_DE.UTF-8(está listada como en_DEse fosse).
No entanto, assim que seleciono esse local específico, entro em problemas. Quando eu agora executo locale, recebo o erro

locale: Cannot set LC_ALL to default locale: No such file or directory

e as localidades listadas agora também são exibidas en_DE.UTF-8para alguns campos.

No meu laptop HP Pavilion executando o Linux Mint 18.3, estou tendo o problema de o sistema gerar gigabytes de arquivos de log em apenas uma ou duas sessões (não mais que meio dia cada).

Os grandes arquivos de log gerados são /var/log/kern.loge /var/log/syslog. Ambos são preenchidos com o seguinte relatório:

Feb 27 13:54:38 workstation kernel: [  390.503777] pcieport 0000:00:1d.0: AER: Corrected error received: id=00e8
Feb 27 13:54:38 workstation kernel: [  390.503786] pcieport 0000:00:1d.0: can't find device of ID00e8
Feb 27 13:54:38 workstation kernel: [  390.503802] pcieport 0000:00:1d.0: AER: Multiple Corrected error received: id=00e8
Feb 27 13:54:38 workstation kernel: [  390.504154] pcieport 0000:00:1d.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e8(Receiver ID)
Feb 27 13:54:38 workstation kernel: [  390.504158] pcieport 0000:00:1d.0:   device [8086:9d1b] error status/mask=00000001/00002000
Feb 27 13:54:38 workstation kernel: [  390.504162] pcieport 0000:00:1d.0:    [ 0] Receiver Error         (First)
Feb 27 13:54:38 workstation kernel: [  390.504172] pcieport 0000:00:1d.0: AER: Corrected error received: id=00e8
Feb 27 13:54:38 workstation kernel: [  390.504180] pcieport 0000:00:1d.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e8(Receiver ID)
Feb 27 13:54:38 workstation kernel: [  390.504185] pcieport 0000:00:1d.0:   device [8086:9d1b] error status/mask=00000001/00002000
Feb 27 13:54:38 workstation kernel: [  390.504190] pcieport 0000:00:1d.0:    [ 0] Receiver Error         (First)

De novo e de novo e de novo outra vez. Esse erro costumava aparecer na inicialização, mas como não parecia afetar minha experiência de trabalho diária após a inicialização, suprimi esses erros com o pci=nomisadicionado a /etc/default/grube, em seguida, executando um arquivo update-grub.

No entanto, obviamente, apenas suprimi a impressão dessas mensagens de erro, pois o log agora está cheio delas.

Eu também tentei usar logrotatepara limitar o tamanho dos arquivos de log, mas isso não tem nenhum efeito, pois o arquivo de log está crescendo tanto em apenas uma sessão.

Alguém tem uma ideia de como posso manter esses arquivos de log em um tamanho aceitável (talvez algumas centenas de MBs no máximo)? Porque agora eu regularmente tenho que excluir esses arquivos de log manualmente para evitar que eles ocupem todo o meu espaço em disco.

EDITAR: saída de lspci -tv:

-[0000:00]-+-00.0  Intel Corporation Sky Lake Host Bridge/DRAM Registers
           +-02.0  Intel Corporation Sky Lake Integrated Graphics
           +-04.0  Intel Corporation Skylake Processor Thermal Subsystem
           +-14.0  Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller
           +-14.2  Intel Corporation Sunrise Point-LP Thermal subsystem
           +-16.0  Intel Corporation Sunrise Point-LP CSME HECI
           +-17.0  Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode]
           +-1c.0-[01]----00.0  NVIDIA Corporation GM108M [GeForce 940MX]
           +-1c.4-[02]----00.0  Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader
           +-1c.5-[03]----00.0  Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller
           +-1d.0-[04]----00.0  Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter
           +-1f.0  Intel Corporation Sunrise Point-LP LPC Controller
           +-1f.2  Intel Corporation Sunrise Point-LP PMC
           +-1f.3  Intel Corporation Sunrise Point-LP HD Audio
           \-1f.4  Intel Corporation Sunrise Point-LP SMBus

Na minha instalação do Linux Mint 18.3, tive problemas com minha configuração de localidade, o que causou a geração de uma pasta com codificação inválida em seu nome.

Agora gostaria de excluir a referida pasta, mas não consigo descobrir como posso fazer isso. Tentei usar meu gerenciador de arquivos (Dolphin) e também o terminal ( sudo rmdir <folder name>), mas ambos os comandos falharam, alegando que a pasta fornecida não existe.

No entanto, ele ainda é exibido no gerenciador de arquivos e por meio do lscomando.

sudo rmdir Einf�hrung in die Biochemie/
rmdir: failed to remove 'Einf�hrung': No such file or directory
rmdir: failed to remove 'in': No such file or directory
rmdir: failed to remove 'die': No such file or directory
rmdir: failed to remove 'Biochemie/': No such file or directory

O nome do diretório foi copiado da saída de ls.

No meu laptop, tenho o Linux Mint 18.3 instalado e agora estou enfrentando o seguinte problema:
Como alemão, tenho alguns arquivos (ou diretórios) que contêm tremas em seus nomes (o que por si só não é o problema). Se eu tentar abrir esses arquivos (por exemplo, PDFs) que contêm um trema ou estão localizados em um (sub-)diretório cujo nome contém um trema, ele não será aberto.

Por exemplo, tenho um diretório chamado Übungsblättere em algum lugar desse diretório tenho alguns arquivos PDF. Se eu tentar abrir um desses arquivos do gerenciador de arquivos, o Okular me dirá que não pode abrir .../Ãbungsblätter/..., o que me mostra que estragou o caminho ao substituir os tremas por alguns caracteres estranhos.

No entanto, se eu tiver o Okular aberto e usar seu menu para abrir o respectivo arquivo, tudo funcionará como um encanto, então o problema ocorre apenas ao tentar abrir os arquivos do meu gerenciador de arquivos (Dolphin).

Além disso, percebi que não consigo digitar tremas no meu terminal. Encontrei esta questão lidando com esse problema específico e esperava que isso também corrigisse o problema do arquivo. No entanto, esse não era o caso, embora agora eu seja capaz de digitar tremas no terminal (embora ao digitar um trema ele insira dois caracteres. Por exemplo, ao digitar ö, inserirá os dois caracteres \udcc3\udcb6(descoberto digitando öe pressionando retornar depois). Ele é exibido como um único ö, mas eu tenho que excluir explicitamente dois caracteres para que a linha de comando fique vazia novamente.

Aqui está a saída de locale:

locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=de_DE.UTF-8
LANGUAGE=en_US
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=nds_DE.UTF-8
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=

EDIT:
Acabei de descobrir que ao abrir o respectivo PDF a partir do terminal também ocorrerá um erro semelhante ao abrir a partir do gerenciador de arquivos, mas desta vez diz que não pode abrir .../bungsbltter/...(remove completamente os tremas)

EDIT2:
Saída de locale -a:

C
C.UTF-8
de_DE.utf8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
POSIX

EDIÇÃO 3:
/etc/default/locale:

LANGUAGE=en_GB.utf8
LANG=en_US.UTF-8

Estou executando o Manjaro Linux no meu laptop HP Pavilion ( 15-au014ng ) e recentemente estou tendo um comportamento estranho:
quando o laptop está desligado, ele descarrega bastante a bateria. Estou perdendo até 40% da bateria durante a noite.

No entanto, esse problema ocorre apenas ao "permitir que o linux desligue o computador" (seja pelo menu Iniciar ou pelo shutdown nowconsole). Se eu desligar meu computador pressionando o botão liga / desliga, a bateria permanecerá a mesma durante o mesmo período.

Atualmente, estou usando o kernel 4.9.71-1 LTS, embora mal consiga acreditar que esse é um problema do kernel, pois não atualizei o kernel (se bem me lembro - existe uma maneira de verificar isso?) e costumava funcionar muito bem. Estou enfrentando esse problema apenas por cerca de 1,5 a 2 meses.

Eu pensei que poderia ser um bug de um dos pacotes instalados e que seria resolvido na próxima atualização, mas não parece ser tão fácil.

Encontrei este artigo sobre o tópico que sugeriu adicionar ethtool -s eth0 wol dao /etc/rc.local.shutdownque fiz (embora tenha substituído eth0, eno1pois este é o nome da minha conexão Ethernet de acordo com ifconfig). No entanto, isso não resolveu o problema.

Também verifiquei a configuração do WOL usando sudo ethtool eno1e ele me mostrou que o WOL deveria ser desativado de qualquer maneira.

A única coisa que notei é que recebo esta mensagem durante a inicialização e também durante o processo de desligamento:

Dez 08 17:25:43 workstation kernel: Bluetooth: hci0: rtl: examining hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723
Dez 08 17:25:43 workstation kernel: Bluetooth: hci0: rtl: loading rtl_bt/rtl8723b_config.bin
Dez 08 17:25:43 workstation kernel: bluetooth hci0: Direct firmware load for rtl_bt/rtl8723b_config.bin failed with error -2
Dez 08 17:25:43 workstation kernel: Bluetooth: hci0: Failed to load rtl_bt/rtl8723b_config.bin
Dez 08 17:25:43 workstation kernel: Bluetooth: hci0: rtl: loading rtl_bt/rtl8723b_fw.bin
Dez 08 17:25:43 workstation kernel: Bluetooth: hci0: rom_version status=0 version=1
Dez 08 17:25:43 workstation kernel: Bluetooth: cfg_sz 0, total size 22496

Embora eu não tenha certeza se isso tem algo a ver com o problema real.

Alguém tem uma ideia de qual pode ser a causa disso e (idealmente) como corrigi-lo?

EDIT:
Parece que esta questão descreve um problema muito semelhante, se não o mesmo (embora com um kernel mais recente).

EDIT2:
Não tenho certeza de quando exatamente esse problema começou, mas sei que instalo todas as atualizações que octopime fornecerão, por isso é absolutamente possível (na verdade, muito provável) que o problema tenha ocorrido com algumas dessas atualizações.
Eu sei, no entanto (acabei de descobrir) que meu kernel está de fato sendo atualizado. Eu sei que quando instalei o Manjaro pela primeira vez no meu laptop, ele veio com o kernel 4.9.47-1. Vou procurar uma maneira de verificar quando essas atualizações do kernel foram realizadas para ver se há alguma conexão.