É bem simples fazer a compilação cruzada de aplicativos x86 em máquinas AMD64 com gcc. Assegure-se de ter os includes e bibliotecas 32 bits instaladas. Pelo menos, tenha os pacotes ia32-libs (as bibliotecas mínimas) e libc6-dev-i386 (para as inclusões). O gcc estará com suporte a multilib (múltiplas bibliotecas).
apt-get install ia32-libs libc6-dev-i386

A partir daí, basta acrescentar a opção -m32 ao compilador gcc.
gcc -m32 -o hello hello.c

Uma arquitetura em particular (i386, i486, pentium etc.), pode ser especificada com -march.
gcc -m32 -march=i386 -o hello hello.c
Fontes:

Debian AMD64 How-to
Debian AMD64 Faq

O objetivo deste post como é executar um programa 32 bits no Debian x86_64. Não tenho idéia de como outras distribuições lidam com essa compatibilidade. Explicarei, então, como o Debian faz, para ver se o método é compatível. Se só quiser saber como instalar o (ou pelo) caso de exemplo, vá para a seção Gens-GS no Debian-AMD64 (x86_64) deste post.

Devido ao suporte nativo da arquitetura x86_64 (desenvolvida pela AMD) à arquitetura x86 (criada pela Intel), o Debian utiliza um método que ele considera uma emulação 32 bits. No diretório raiz do sistema, criou uma pasta /emul onde lá estariam as arquiteturas emuladas: no caso /emul/ia32-linux/.

Nesse diretório, fica “toda” a árvore do sistema de arquivos para aplicativos 32 bits. “Toda” porque, na verdade, só a pasta usr/ e lib/ ficam lá. Os aplicativos 32 bits usarão as pastas nativas para arquivos de configuração, registro etc (/etc/ e /var/, por exemplo).
Além disso, dentro da pasta /usr/ “oficial” do sistema, criou duas novas pastas: lib32/ e lib64/. A pasta /usr/lib/ é uma ligação para /usr/lib64/, diretório no qual residem todas as bibliotecas 64 bits, como o própio nome sugere.

Ao se executar um programa que se vale de bibliotecas dinâmicas (ou seja, quase todos), conforme a arquitetura do aplicativo, ele vai procurar primeiro a biblioteca compatível no pasta das de 32 bits; caso não encontre, recai nas de 64 bits. Contudo, não adianta tentar fazer a ligação dinâmica de programas 32 bits com bibliotecas 64 bits, ocorre erro na quase totalidade dos casos. Então, o que se deve fazer é instalar as bibliotecas 32 bits faltantes.

Primeiramente, para poder rodar os aplicativos 32 bits menos exigentes em bibliotecas, o mínimo que se deve instalar é o pacote ia32-libs. Para aplicativos com interface gráfica que utilizam GTK+, deve se instalar ia32-libs-gtk. O pacote lib32nss-mdns, por sua vez, é para auxiliar nas conexões com a internet (relativos a DNS).

Passemos a um exemplo de caso, agora, em que essas bibliotecas não são o suficiente:

———————————————————————-
Gens-GS no Debian-AMD64 (x86_64)
———————————————————————-

Esse aplicativo citei em outro post, referente a emuladores de sistemas SEGA. No caso, é um emulador de Mega Drive.
Esse Gens modificado ainda não terminou de reescrever o código para que possa ser portado enfim para 64bits. No entanto, dá para executá-lo no Debian instalando as bibliotecas 32 bits que ele disponibiliza.
Como é um aplicativo 32 bits, e usa a interface GTK+, é necessário instalar dois pacotes:

• ia32-libs
• ia32-libs-gtk

Como gosto do aptitude pela memória que ele tem para remoção das dependências depois que o pacote que as convocou é removido, sempre o uso:
# aptitude install ia32-libs ia32-libs-gtk
Quem não gosta, ou prefere o apt-get:
# apt-get install ia32-libs ia32-libs-gtk
Ou utilize synaptic para fazer com uma amigável GUI. Os programas devem ser executados como super-usuário (root) ou via sudo.

Feito isso, podemos instalar o pacote pré-compilado do Gens-GS para Ubuntu 32 bits. Para tal feito, é preciso obrigar o utilitário dpkg a instalar o pacote ignorando o problema de arquitetura…
# dpkg --force-architecture -i meu-diretório/Gens_2.15.5-gs-m6-1_i386.deb
Instalado com sucesso, é o momento de executarmos o emulador:
$ gens
E então ocorre o momento que todos “queriam”: o erro.
$ gens
gens: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
Ou, em português,
$ gens
gens: erro ao carregar as bibliotecas dinâmicas: libGL.so.1: não é possível abrir o arquivo objeto compatilhado: O arquivo ou o diretório não existe

Ou seja, o sistema não encontrou as bibliotecas 32 bits do OpenGL que o Gens-gs precisa (na verdade, na execução, você pode optar por usar SDL). O que é preciso fazer, então, é instalá-las. Suponhamos que você não saiba em que pacote que elas vêm. É possível usar o site de pacotes do Debian para pesquisar. No caso, é preciso buscar pelo conteúdo do pacote: libGL.so.1. Na página do resultado da pesquisa para a versão debian/lenny, observa-se alguns pacotes possíveis:

• fglrx-glx-ia32 [amd64] : para placas de vídeo AMD/ATI
• nvidia-glx-ia32 [amd64] ou nvidia-glx-legacy-96xx-ia32 [amd64]: para placas de vídeo da NVIDIA
• libgl1-mesa-glx [i386, amd64]: para renderização direta ou indireta

“Tanto faz” qual utilizar. Óbvio que para melhor desempenho, deveria utilizar o apropriado para sua placa de vídeo.

Para generalizar a solução, vou escolher o pacote libgl1-mesa-glx. Embora tenha a versão própria para AMD64, nós precisamos é da versão 32 bits (repare que os demais pacotes citados já são para isso – 32 bits em máquinas 64 bits, o que é bem melhor).

O que se deve fazer é baixar o pacote para i386 do site do Debian:
http://packages.debian.org/lenny/libgl1-mesa-glx

E fazer o dpkg, em vez de instalar de fato no sistema, apenas extrair para a pasta de emulação de 32 bits…
# dpkg --extract meu-diretório/libgl1-mesa-glx_7.0.3-7_i386.deb /emul/ia32-linux/
Et voilà! Gens/GS funciona enfim.

Lembro que deve isso ser feito como super-usuário, que o que deve ficar na pasta /emul/ia32-linux/ são apenas as lib/ e usr/, as demais, se criadas, devem ser apagadas ou ter seu conteúdo movido para as equivalentes do sistema.

Destaco aqui que é/seria muito melhor instalar os pacotes *-ia32. Essa solução é para quando não estão disponíveis. Esse método pode ser melhorado modificando o pacote já para fazer a instalação nas pastas adequadas e modificando a arquitetura de instalação: isso permite remover o conteúdo do pacote depois com apt-get, aptitude, synaptic etc. Contudo, foi feito assim por simplicidade.

Descobri novos emuladores de sistemas da SEGA para o Linux em relação a um post anterior.

Emulador de Master System:
osmose: Enfim um emulador com som no meu Debian 64 bits. Só conhecia o Meka, que não consegui rodar com som, já que está bem desatualizado sua versão linux.

Emuladores de Mega Drive:
gens-gs : Modificação do Gens oficial, que pretende juntar todos os mods de Gens disponíveis e reescrever tudo para a linguagem C (existem partes em assembly i386). Por ora, sem suporte a 32 bits. Consegui executá-lo direito aqui, mas isso é assunto para outro post. Muito bom, mas há erros no som, como quase todos os emuladores de mega-drive.
regen: Tem a intenção de ser o mais perfeito de todos em termos de emulação, inclusive no sincronismo. Tem as mesmas falhas de som que o Gens, contudo. A versão linux, sempre desatualizada perante a windows, é só para 32 bits, mas executável da mesma forma que o Gens/Gs em sistemas 64 bits. Aliás, mais fácil.

Emulador de Saturn:
yabause: Nunca testei, não tenho jogos de Saturn (nem nunca joguei um…). Uns gostam, outros não. O que sei é que existe nos repositórios do Debian, inclusive para 64 bits

Emulador de Dreamcast
lxdream: Ótimo emulador, embora o desenvolvimento dele tenha caído de velocidade. Já o mencionei aqui antes, mas não ia deixar o último sistema da SEGA fora dessa lista

O Osmose, o Gens/gs e o Yabause foram dicas de um amigo meu. Embora ainda não tenha divulgado em lugar algum sobre o Osmose, ele já noticiou sobre Gens/gs e Yabause.
O Yabause também foi me notificado pelo Leandro Santiago em um comentário neste blog (embora seja querendo outro emulador para o Saturn…)

Não lembro a tradução oficial desse recurso chatíssimo do protocolo do ex-MSNM (Microsoft Network Messenger), agora WLM (Windows Live Messeger): o nudge é aquilo que um contato faz para chamar atenção do usuário para a conversa. Para isso, emite um som, treme a tela e aparece a janela do batepapo na frente de todas as outras janelas do windows.

Pidgin (antigo GAIM) e Kopete são dois clientes que uso ou usei no Linux e ambos têm esse recurso, mas se resumem a notificar textualmente e, no máximo, sonoramente. Embora ambos recebam e notifiquem o nudge, eu acreditava que o Pidgin perdia para o Kopete neste recurso porque não havia como enviar um nudge (que o Kopete traduz como “abanão”) Pidgin. Mas agora descobri pela internet que pode sim. Basta imaginá-lo como um cliente de IRC e enviar a mensagem
/nudge
na janela de batepapo. Destacando, só escreva isso e pressione a tecla [Enter].
/me fiz alguma coisa
também funciona como esperado em um cliente de IRC.

—
Comentários pessoais
Não costumo expor opiniões aqui, mas desta vez irei, só que ainda assim de forma contida.

• Detesto este recurso, é muito mal usado por brasileiros, pelo menos. A idéia é ótima, mas ficam brincando ou chamando atenção para algo completamente irrelevante… Ainda bem que sou salvo disso por usar clientes diferentes dos oficiais do protocolo MSNP.
• Como a Microsoft tem problemas de criatividade ou de subestimar a inteligência e memória de seus clientes: depois do MS-DOS (sigla em inglês para sistema operacional em disco como se fosse o primeiro e único), MS-Windows (como se a Apple não usasse o termo janela), MS-Internet Explorer (UAU!), ela vem com Windows Messeger, MSNM (Mensageiro da rede Microsoft) e Windows Live Messeger… Tsc tsc. Viva Excel e Access, nomes que não têm nada a ver com nada!
• Eita gente ignorante que nunca viu a letra m em minúscula na sigla do programa: MSNm…. MSN é um serviço da Microsoft muito aquém de um mero mensageiro (mas não que prestasse)
• Esse protocolo um dia permitirá os “sempre visíveis” como no antigo e excelente ICQ?
• Esse cliente/protocolo um dia permitirá bloquear o grupo (afinal, esse recurso precisa de uma utilidade maior que esconder quem não te interessa no momento)?
• Apesar de eu não usar, o Pidgin deveria disponibilizar o nudge como botão… Para mim, o Pidgin ainda perde neste quesito para o Kopete.

Bom, eu perdi o passo-a-passo que executei para renovar a forma de digitar caracteres japoneses de forma diferente da que fiz em um post anterior… Aliás, faz MUITO tempo que fiz essa troca, mas não registrei aqui.

O método de entrada que uso agora é o uim-anthy (método de entrada anthy (front-end) sobre a biblioteca uim (backend)). É muito bom. Juntamente com o seus applets disponíveis (para GNOME e KDE), a vida fica muito mais fácil e prática.

Não lembro muito o que eu fiz exatamente, como já disse, mas segue o que tenho agora no meu sistema (Debian Lenny AMD64). Tenho instalados os pacotes:

• uim-anthy (que instalará anthy, libanthy0, libuim6, uim-common, uim-utils)
• uim-applet-gnome (mas existe também o uim-applet-kde)

Acredito que basta instalar esses dois pacotes (e suas dependências, claro). Claro que seu sistema tem que ter fontes japonesas ou com suporte à língua japonesa.

Caso eu esteja enganado, uma página boa (acho) como referência é Aletéia. Só um detalhe: não precisei de instalar nada de scim, que é uma alternativa mais antiga ao uim.

Para quem não quer instalar nada (e também para usuários de MS-Windows), existe uma página que permite digitação em caracteres japoneses usando apenas o navegador web.
Testei, e funciona no Opera, meu navegador. Essa dica peguei do grupo de discussão NihongoBR do qual não participo. No entanto, não usarei essa página, já que não preciso…

Bom, ao comprar periféricos novos, é muito difícil ter certeza ou não do seu funcionamento pleno no Linux, dado o descaso dos fabricantes em dar suporte ao Linux. Sorte nossa que há muitos desenvolvedores que gostam desse desafio de fazer engenharia reversa

Este post aqui é só para informar que o produto USB Bluetooth adaptor EM-BT1 (baseado no Bluetooth Dongle v2.0), da ECOmania, funcionou sem qualquer problema no meu Debian/Etch. Automaticamente! Claro, tenho instalados os pacotes referentes a Bluetooth: bluetooth e bluez-utils.

Fica aí reportado para quem tiver dúvida se compra ou não ;)

Como a ATI lançou uma nova versão de seu driver (8.476), resolvi atualizá-lo.

Segui meus passos relatados no post anterior. Reiniciei a interface gráfica e… não funcionou! Ficou bem estranho mesmo: a tela preta com algo verde. Tentei mudar para o modo terminal tty1 (CTRL+ALT+F1) e nada: mesma coisa esquisita! Apertei então o famoso CTRL+ALT+DEL para reiniciar e ver se isso corrigiria o problema. Continuou igualzinho!

Tive que reiniciar o PC de novo e tentar entrar no modo terminal. Meu bootloader GRUB tinha como opção de boot o modo single-user. Ai de mim se não tivesse =P

Para os que não têm, dá para resolver na tela do GRUB mesmo. Selecione o kernel que você quer usar e pressione E em vez de ENTER. Isso faz entrar no modo de edição (não permanente). Acrescente o argumento single. No meu caso, é assim:

/boot/vmlinuz-2.6.18-6-amd64 root=/dev/hda3 ro single

Pressione ENTER então para dar o boot. Quando chegar o momento, pedirá a senha de root. Digite-a Pronto! Modo terminal!

Depois de reinstalar as versões anteriores (eu já tinha os pacotes prontos, só precisei executar o dpkg -i), descobri o problema: esqueci de usar o module-assistant para gerar o módulo do novo driver para o kernel. Isto é:
# module-assistant prepare
# module-assistant update
# module-assistant a-i fglrx

Pressionei CTRL+ALT+D para fazer log-off e assim o sistema terminar de iniciar. E ok!
Conclusão, nunca esqueça de gerar o novo módulo antes de reiniciar! Ah! Descobri também que nem sempre só reiniciar o servidor X resolve!

O desempenho do OpenGL caiu (drasticamente) na minha máquina, e procurei saber o que era. Meu driver da ATI não estava servindo para nada. Para me informar disso, usei o comando:
$ glxinfo | head
A terceira linha retornada foi:
direct rendering: No

Usei, então, o comando:
$ fglrxinfo
E a resposta foi que o “OpenGL vendor string” era Mesa (indirect) em vez de ser meu driver ATI Radeon Xpress series.

Motivo descoberto: atualizei o kernel e o módulo não estava mais funcionando

Tive, então, que relembrar os passos que segui outrora. Só baixar o driver do fabricante e rodar o instalador não funciona!
Em todo caso, é necessário baixar o driver correto, sendo que o meu é Radeon Xpress para 64bits (o arquivo baixado foi ati-driver-installer-8.443.1-x86.x86_64.run).

Uma vez descarregado o arquivo, em vez de mandar instalá-lo, é melhor fazer gerar os pacotes para posteriores instalações, quem sabe?
$ sh ./ati-driver-installer-8.443.1-x86.x86_64.run --buildpkg Debian/etch
Obs.: Se alguém estiver usando para outra distribuição, obtenha a lista das possíveis usando o comando
$ sh ./ati-driver-installer-8.443.1-x86.x86_64.run --listpkg

Eis a lista de pacotes gerados:

• fglrx-amdcccle_8.443.1-1_amd64.deb
• fglrx-driver_8.443.1-1_amd64.deb
• fglrx-driver-dev_8.443.1-1_amd64.deb
• fglrx-kernel-src_8.443.1-1_amd64.deb

Além do arquivo texto:

• fglrx-installer_8.443.1-1_amd64.changes

Construídos os pacotes, hora de instalá-los, seja via apt-get, seja por dpk.
$ dpkg -i fglrx*443*deb
(eu tinha outra versão na mesma pasta)

Agora que veio a parte que eu não me lembrava. Contudo, graças a um link no site da própria ATI para um site não oficial, achei o que precisava.

Faltava gerar o módulo para o kernel! Que até agora não sei por que não geram no instalador =P

$ module-assistant prepare
$ module-assistant update
$ module-assistant a-i fglrx

Caso não possua o module-assistant, obtenha-o via apt-get.

Não sei se é necessário isso aqui, mas a página falou, tá falado.
$ aticonfig --initial

Agora a página sugere reiniciar o computador. Não precisa. Bastou reiniciar o servidor gráfico (o X): Ctrl+Alt+Backspace. Lembre-se de que tudo será fechado (quase) instantaneamente, salve tudo antes de apertar essas teclas! Se preferir, faça log-off e só então reinicie o X.

Reiniciado o servidor gráfico, efetuei o login e executei o comando:
$ fglrxinfo

Et voilà, a mensagem que eu tanto almejava!

display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Radeon Xpress Series
OpenGL version string: 2.1.7170 Release


E tudo voltou ao que era antes…

Seguindo as instruções de um post meu mesmo “antigo”, fui capaz de gerar um assembler e linker para o processador Z80, que o Megadrive usa como coprocessador de som e o Master System como principal (e única) CPU.

A única diferença é que, infelizmente, não há suporte para arquivos-objeto ELF ainda (binutils versão 2.18), só COFF. E, esquisitamente, só permite rodar o configure, se o alvo (–target) for z80-unknown-coff. O resto seguiu sem maiores problemas.

Meus agradecimentos à WikiTI por me dar essa informação sem saber =]

Conectei pela primeira vez a minha câmera no meu Debian Etch + Gnome…

Para meu espanto, apareceu uma janela de diálogo Importar de câmera informando que uma câmera fotográfica foi detectada e perguntando se eu queria importar as fotos.

Cliquei no botão Importar fotos e… nada =P Isso porque a idéia é executar o programa gthumb e ele não estava instalado. Mas custava avisar?

O programa responsável por isso é o gerenciador de volumes (de armazenamento de dados) do GNOME, o programa gnome-volume-manager. Para configurá-lo, pode usar o programa gnome-volume-properties, também acessível por Desktop > Preferências > Unidades e Mídias removíveis.