domingo, 22 de dezembro de 2013

Problemas para compilar com libGL.la

libtool resolvendo problemas

Tentando compilar o fonte do geany-plugins (para ter o corretor ortográfico) encontrei problemas com um handler do libGL.la. Para resolver o problema, tive que começar do começo, partindo da seguinte pergunta: O que é o libGL.la?


Os arquivos *.la são pequenos arquivos de texto puro que contém informações uteis para o libtool, como versões de bibliotecas e localização das mesmas.


Meu primeiro problema foi:


libtool: link: cannot find the library `/usr/lib/libGL.la' or unhandled argument `/usr/lib/libGL.la'


Depois de orar para o deus google (ele sabe tudo e esta em todo lugar) descobri uma dica para criar o arquivo manualmente. O que obviamente seria um estresse a mais, já que estava cansado disso. Descobri em um blog em inglês uma boa dica para criar o arquivo 'vazio' (apenas com os itens a serem preenchidos). Pensei com meus botões (o terceiro botão de cima para baixo sempre me dá dica boa, já os outros...) seria mais fácil assim, depois encontro as informações que preciso e completo o arquivo. O comando foi rodado em /usr/lib:


libtool --mode=link gcc -g -O -o libGL.la /usr/lib/libGL.so


Depois de executado, o comando cria, dentro do diretório em que você estiver, um arquivo mais ou menos assim:


# libGL.la - a libtool library file
# Generated by libtool (GNU libtool) 2.4.2
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname=''

# Names of this library.
library_names=''

# The name of the static archive.
old_library='libGL.a'

# Linker flags that can not go in dependency_libs.
inherited_linker_flags=''

# Libraries that this one depends upon.
dependency_libs=''

# Names of additional weak libraries provided by this library
weak_library_names=''

# Version information for libGL.
current=
age=
revision=

# Is this an already installed library?
installed=no

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir=''


Observe que o arquivo está 'vazio', por isso ao rodar o slackbuild do geany-plugins o erro passou a ser arquivo inválido. O próximo passo seria encontrar os dados sobre o libGL.so para completar o arquivo. O libGL.so fica em /usr/lib. Procurando um jeito de obter essas informações, encontrei uma resposta mais completa sobre o erro aqui. Pelo texto, temos um comando mais completo que não só cria o arquivo vazio, mas o preenche com as informações (ainda estou estudando o manual no libtool para entender em detalhes o que o comando faz), embora a dica seja de 2006, para slackware 10, aqui no meu slackware 14 funcionou direitinho.



O comando deve ser executado dentro do diretório /usr/X11R6/lib, que na verdade é um link para /usr/lib:


libtool --mode=link gcc -g -O -o libGL.la -rpath /usr/X11R6/lib -lm

Depois disso, o slackbuild conseguiu rodar direito e criar o pacote. O mais interessante entre os dois comandos, é que o segundo cria o libGL.la e o preenche com... zeros. Isso mesmo, a maior parte das informações inseridas pelo segundo comando se limitou a "0", mas tudo funciona direitinho, então para que reclamar né?



Por hoje é só pessoal. =]

Continue Lendo >

domingo, 15 de dezembro de 2013

Slackware 14 Vs Debian 7.1

O que aprendi usando Debian Wheezy

Há alguns messes meu KDE começou a não entrar, o HD apanhava e nada. Tudo muito lento e instável. A principio culpei o Slackware 14, que em comparação ao 13.31 é bem "ruinzinho". Por isso resolvi formatar a partição raiz e dar uma oportunidade ao Debian.

Usei o Debian 7.1 (codinome Wheezy) nos últimos cinco messes, e posso dizer que estou feliz... em voltar para o Slackware 14.


De modo geral, as principais picuinhas do Slackware são, não tem um gerenciador de pacotes similar ao apt-get (do Debian) e também demorar messes para surgir versões .txz dos programas, o que obriga instalar tudo no braço.


O que aprendi com o uso do Debian é que instalar no braço é muito melhor, tudo roda melhor, as versões são atualizadíssimas (afinal você baixou o código fonte mais recente, antes mesmo dele virar pacote da sua distribuição). A não subordinação ao repositório da distribuição se mostrou incrivelmente satisfatório para mim.
A maior vantagem do Debian é ter um grande repositório de programas (pelo menos essa era a propaganda que eu ouvia dele), mas achei o Debian com repositório oficial fraquinho onde há uma incessante necessidade de incluir repositórios backdoor para conseguir atualizar o hplip, o icewise (versão firefox usada pelo Debian) etc.


Sobre o Slapt-get (a versão slackware do apt-get) ele consegue resolver os problemas mais fundamentais de dependências de pacotes, mas não é um apt-get. Muitas vezes é preciso resolver questões de dependências na unha (o que pode ser imensamente chato para uma dependência obscura) mas depois do trabalho duro, tudo fluí muito melhor.


O Slackware também se mostrou melhor, pelo menos para mim, na questão uso do HD (no frigir dos ovos o problema era na configuração do KDE e meu HD que pediu aposentadoria em função da idade). O debian e seus derivados tem um tal de trackerqualquercoisa que são três programas que leem todo ao conteúdo do hd sempre que o sistema inicializa. Esses programas tomam toda a carga da CPU enquanto fazem sua tarefa, o que deixa tudo lento por alguns bons minutos, além de usarem o HD por todo o tempo. o Slackware não tem disso, e para mim se mostra vantajoso, mesmo com o KDE, que só requer que se desative o Nepomuk/Strigi.


Obvio que o Debian tem seus méritos, e são muitos, mas para mim que aprendi a usar o Slackware e me sinto confortável com sua atitude espartana, o debian foi um tanto decepcionante.


Até a próxima


Continue Lendo >

domingo, 16 de junho de 2013

Juk, Amarok e outros que não tocam mp3 no Slackware 14

Resolvendo problemas com plugins

Passei para o slackware 14 a alguns meses e estava lutando para fazer o Juk e o amarok tocarem mp3. Os Mplayer, kplayer e Xine rodando tudo numa boa, plugins do Mplayer todos instalados e atualizados. Mas Juk e Amarok só tocando ogg.


Depois de muito pesquisar e lutar, encontrei um repositório para o slapt-get que funciona, pois o http://darkstar.ist.utl.pt/slackware/addon/slacky/slackware-14.0/ não está validando a chave de checksum a meses. Usei a alternativa http://slack.isper.sk/pub/slackware-14.0/. Basta adiciona-lo no /etc/slapt-get/slapt-getrc:


SOURCE=http://slack.isper.sk/pub/slackware-14.0/


Com um repositório melhor na mão, só bastava saber o que está faltando para que o juk toque mp3. Verifiquei o GSTreamer e está atualizado.


Mas, e aqui vem o detalhe da questão, o gstreamer teve que se desmembrar pois alguns plugins dele são código proprietário, assim para tudo funcionar é preciso bem mais do que apenas o pacote gstreamer instalado. Embora eu tenha pesquisado um lista enorme de pacotes (geralmente começando com gst-), para mim só foi necessário instalar um:


#slapt-get -i gst-plugins-ugly


Isso foi tudo que precisei. Uma lista mais extensa dos repositórios disponíveis para o slapt-get pode ser encontrada em: http://repository.slacky.eu/slapt-get.txt

Continue Lendo >

domingo, 21 de abril de 2013

BibTex - O que ninguém conseguiu me dizer.

Por que o bibtex não funciona na classe document.

Há alguns dias, revisando as postagens antigas no blog (infelizmente ando meio sem tempo para atualizá-lo com mais frequência) de deparei com um comentário sobre o bibtex. Um leitor do blog me dizia que ainda não conseguia fazer funcionar...


Eu sempre usei o bibtex em conjunto com o pacote ABNTEX, e nunca havia reparado que sem ele o bibtex acusa um erro: falta um arquivo de estilo .bst. A classe abntex tem seu próprio abntex.bst e por isso funciona. Mas compilando um arquivo na classe book é preciso indicar que arquivo de estilo o bibtex deve usar.


Isso deve ser feito com a seguinte comando:


bibliographystyle{}


Que deve estar antes do bibliography. A questão passa a ser quais são os arquivos de estilo disponíveis? onde eles estão?


A segunda questão foi respondida com uma rápida olhada na partição raiz. Em /usr/share/texmf/bibtex encontrei um subdiretório bst. Nele doze subdiretórios com arquivos de estilo .bst. O que por fim, respondeu a primeira pergunta.


Testando alguns deles, descobri que os estilos do subdiretório base são acessíveis diretamente. Mas alguns estilos dos outros subdiretórios requerem a inclusão de pacotes específicos, como por exemplo os estilos do subdiretório natbib requem a inclusão do pacote natbib, com o comando obvio usepackage{natbib}. O estilo padrão do latex é o plain que está no subdiretório base. O arquivo deve ser referido no comando sem a extensão.


Parece simples, e realmente é. Apenas com a inclusão do estilo o bibtex funcionou com todas as classes Latex que suportam referências bibliográficas. Mas o mais estranho, é o fato de que eu não achei nada, em lugar algum, que me dissesse isso. Uma informação ao mesmo tempo tão importante e tão trivial, que não aparece nem na 'Não tão pequena introdução ao LaTeX'.


Nerdices a mil. Até a proxima.

Continue Lendo >

sábado, 20 de abril de 2013

ePub

Vindo do LaTeX para o ePub

Quando se fala em divulgação de documentos pela web, pensamos logo em PDF. É portátil, não permite alteração do texto e relativamente seguro. Mas quando falamos de ler um arquivo numa tela de 6 ou 7 polegadas, os PDF's começam a mostrar suas fraquezas.
Mas como tudo tem solução, para os e-reader da vida, temos o formato aberto ePub. Dinâmico e leve, é ideal para dispositivos moveis de tela pequena.

Pensando nisso, comecei a procurar um meio de converter meus pdf's em ePub's. Para minha surpresa não existe um comando LaTeX que converta diretamente o código LaTeX para ePub. Num primeiro momento, pensei "como não tem?, se existe o pdflatex para criar pdf's a partir do latex... poxa pdf é formato proprietário.


Mas com um pouco de pesquisa descobri os 'segredos' do ePub. Para quem quiser conhecê-los um pouco, eu preparei um pequeno guia para conversão de latex para epub. E de quebra conheci um ótimo programa para editar os metadados de PDF's, ePub e afins.


Clique ali(para sair um pouco do tal de 'clique aqui') para baixar a versão PDf do tutorial :epub.pdf

E claro a versão epub do mesmo tutorial: epub.epub


Se você quer um livro para ler no PC, recomendo a versão PDF, mas se você quer para um tablet ou e-reader, a versão ePub é muito melhor.


Nerdices a mil.

Continue Lendo >