Biblioteca (computação)

 Nota: Para outros significados de Biblioteca, veja Biblioteca (desambiguação).

Na ciência da computação, biblioteca (em inglês: library) é uma coleção de subprogramas utilizados no desenvolvimento de software; estes contém funções e dados auxiliares que podem ser usados em programas independentes, o que permite o compartilhamento e a alteração de código-fonte e dados de forma modular. Alguns executáveis são tanto programas independentes quanto bibliotecas, mas a maioria das bibliotecas não são executáveis. Executáveis e bibliotecas fazem referências mútuas conhecidas como ligações, tarefa tipicamente realizada por um ligador.

Ilustração de uma aplicação que pode utilizar libvorbisfile.so para reproduzir um arquivo Ogg Vorbis

A maior parte dos sistemas operacionais modernos provê bibliotecas que implementam a maioria dos serviços do sistema, que transformaram em comodidades os serviços que uma aplicação moderna espera que sejam providos pelo sistema operacional. Assim sendo, a maior parte do código utilizado em aplicações modernas é fornecido por estas bibliotecas.

Uma biblioteca personalizada pode ser impementada usando o recurso "code snippets" ou "snippet", uma forma de automação de código-fonte, que garante economiza tempo e evita erros comuns, assim aumentando a produtividade para o desenvolvedor evitando tarefas repetitivas de programação. Onde o Snippet são pequenas partes reusáveis de um código-fonte ou de um texto.

Visão geral

Bibliotecas podem ser classificadas pela maneira como são compartilhadas, pela maneira como são ligadas e por quando são ligadas.

Bibliotecas tradicionais

Historicamente, as bibliotecas consistiam de um conjunto de rotinas que eram copiadas para uma aplicação-alvo pelo compilador ou ligador, produzindo uma aplicação executável independente, ou standalone. Os fabricantes de compiladores proviam bibliotecas-padrão (por exemplo, a biblioteca padrão do C), mas os programadores também podiam criar suas próprias bibliotecas para uso próprio ou distribuição.

Ligação dinâmica

Ligação dinâmica significa que os dados em uma biblioteca não são copiados para um novo executável ou biblioteca em tempo de compilação, mas permanecem a um arquivo separado no disco. O ligador realiza uma quantidade mínima de trabalho em tempo de compilação—ele apenas grava quais bibliotecas são necessárias para o executável em um índice. A maior parte do trabalho é feita quando a aplicação é carregada em memória ou durante a execução do processo. O código de ligação necessário é na verdade parte do sistema operacional subjacente. Na hora apropriada, o carregador do programa encontra as bibliotecas relevantes no disco e adiciona os dados relevantes da biblioteca no espaço de memória do processo.

Alguns sistemas operacionais são apenas capazes de ligar uma biblioteca em tempo de carregamento, antes que a execução do processo se inicie; outros podem ser capazes de esperar até depois do início da execução e apenas ligar a biblioteca quando ela for referenciada (ou seja, durante o tempo de execução). Este último é freqüentemente chamado de "carregamento atrasado". Em ambos os casos, a ligação é dita dinâmica.

Plugins são uma utilização comum de bibliotecas de ligação dinâmica, algo especialmente útil quando as bibliotecas podem ser substituídas por outras com interfaces similares, mas funcionalidades diferentes. Diz-se que um software possui uma "arquitetura de plugins" se ele utiliza bibliotecas para funcionalidades essenciais com a intenção de que elas possam ser substituídas. Note, entretanto, que o uso de bibliotecas de ligação dinâmica na arquitetura de uma aplicação não necessariamente significa que elas possam ser substituídas.

A ligação dinâmica foi originalmente desenvolvida no sistema operacional Multics, a partir de 1964. Ela também era uma característica do Michigan Terminal System, construído no final dos anos 1960. No Microsoft Windows, bibliotecas de ligação dinâmica são chamadas dynamic-link libraries.

Realocação

Uma sutileza com a qual o carregador de programas tem que lidar é que a localização real dos dados da biblioteca não é conhecida até que o executável e todas as bibliotecas a ele associadas sejam carregadas para a memória. Isto se deve ao fato de que as localizações de memória utilizadas dependerão de quais bibliotecas foram carregadas. Não é possível armazenar uma localização absoluta para os dados dentro do próprio executável, nem mesmo na biblioteca, uma vez que isto resultaria em conflitos entre diferentes bibliotecas. Isto é, se duas bibliotecas distintas alocassem espaços de memória iguais ou sobrepostos, seria impossível usar as duas no mesmo programa. Isto pode vir a mudar com a adoção de arquiteturas de 64-bits, pois elas oferecem endereços de memória virtual suficientes para garantir que cada biblioteca escrita receba sua faixa de endereços única.

Seria possível, em teoria, examinar o programa durante o tempo de carregamento e substituir cada referência a dados na biblioteca por ponteiros para as posições de memória apropriadas uma vez que todas as bibliotecas tivessem sido carregadas. Contudo, este método consumiria quantidades inaceitáveis de tempo ou memória. Em vez disso, a maioria dos sistemas de bibliotecas dinâmicas cria uma tabela de símbolos com endereços vazios no programa em tempo de compilação. Todas as referências ao código ou dados na biblioteca passam por esta tabela, chamada diretório de importação. Durante o tempo de carregamento esta tabela é modificada com a localização dos códigos e dados na biblioteca pelo carregador de programas. Este processo ainda é lento a ponto de comprometer a performance de programas que façam uso de outros programas a uma taxa muito alta, como é o caso de alguns shell scripts.

A biblioteca, por sua vez, contém uma tabela com todos os métodos que a compõem, conhecidos como pontos de entrada. Chamadas à biblioteca passam por esta tabela, procurando pela localização do código na memória e então os executando. Isto introduz uma sobrecarga na chamada de biblioteca, mas o atraso é, em geral, tão pequeno que pode ser negligenciado.

Localizando bibliotecas em tempo de execução

Ligadores e carregadores de programas dinâmicos variam amplamente em funcionalidade. Alguns dependem de caminhos explícitos armazenados no arquivo executável. Qualquer modificação no nome da biblioteca ou layout do sistema de arquivos causará falha nestes sistemas. Mais comumente, apenas um nome da biblioteca (e não do caminho) é armazenado no executável, e o sistema operacional provê um sistema para encontrar a biblioteca no disco, baseado em algum algoritmo.

• A maioria de sistemas Unix-like possuem uma "busca de caminho" especificando o sistema de arquivos no qual procurar as bibliotecas dinâmicas. Em outros sistemas, o caminho padrão é especificado em um arquivo de configuração; em outros, é codificado no carregador de programas dinâmico. Alguns formatos de arquivos executáveis podem especificar diretórios adicionais nos quais procurar por bibliotecas de um programa em particular. Ele pode geralmente ser relido com uma variável de ambiente, embora ela esteja desabilitada para programas setuid e setgid, então o usuário não pode forçar tal programa a rodar código arbitrário. Desenvolvedores de bibliotecas são encorajados a colocar suas bibliotecas dinâmicas em locais no caminho de busca padrão. Por outro lado, isto pode tornar a instalação de novas bibliotecas problemática, e estes caminhos conhecidos rapidamente se tornarem padrão para um número crescente de arquivos de biblioteca, tornando o gerenciamento mais complexo.
• O Windows verifica o Registro do Sistema para determinar o lugar próprio para achar uma DLL ActiveX, mas para outras DLL ele verifica o diretório de onde o programa foi carregado; o diretório corrente de trabalho (somente nas antigas versões de Windows); quaisquer diretórios selecionados pela chamada da funçãoSetDllDirectory(); os diretórios System32, System e Windows; e, finalmente, os diretórios especificados pela variável de ambiente PATH.
• O OpenStep usa um sistema mais flexível, coletando uma lista de bibliotecas de um número conhecido de localizações (similar ao conceito de PATH) quando o sistema se inicia. O deslocamento de alguma biblioteca não causa problemas, no entanto um tempo maior será necessário durante o primeiro início do sistema.

Uma das grandes desvantagens da ligação dinâmica é que os executáveis dependem de bibliotecas armazenadas separadamente para o correto funcionamento. Se uma biblioteca é apagada, movida, ou renomeada, ou ainda se uma versão incompatível de uma DLL é copiada para o lugar onde é procurada, o executável pode ter mal funcionamento ou mesmo falhar no carregamento; danificando arquivos vitais usados por quase todos os executáveis do sistema (como a biblioteca Clibc.so nos sistemas Unix), tornando o sistema inoperável. No Windows isso é comumente chamado de DLL hell.

Carregamento dinâmico

O Carregamento dinâmico é um subconjunto da ligação dinâmica em que uma biblioteca ligada dinamicamente é carregada ou descarregada do sistema em tempo de execução após requisição. A requisição pode ser feita implicitamente em tempo de compilação, ou explicitamente em tempo de execução. Requisições implícitas são feitas ao adicionar referências às bibliotecas a um arquivo objeto pelo ligador. Requisições explícitas são feitas pelas aplicações através do uso de uma API de ligação.

A maioria dos sistemas operacionais que suportam a ligação dinâmica também suportam o carregamento dinâmico através de uma API específica. Por exemplo, o Windows utiliza as funções da API LoadLibrary, LoadLibraryEx, FreeLibrary e GetProcAddress para DLL; incluindo a maioria dos UNIX e UNIX-like, sistemas baseados em POSIX usam dlopen, dlclose e dlsym.

Bibliotecas remotas

Outra solução para a questão das bibliotecas é utilizar executáveis completamente separados e chamá-los através de chamadas de procedimento remoto (RPC). Essa abordagem maximiza o reaproveitamento do sistema operacional: o código necessário para suportar a biblioteca é o mesmo usado para prover o suporte e a segurança da aplicação para os outros programas. Adicionalmente, esse sistema remoto não requer que a biblioteca esteja na mesma máquina do executável, as chamadas podem ser transmitidas por uma rede.

A desvantagem é que cada chamada da biblioteca implica uma sobrecarga considerável. Entretanto, essa abordagem tornou-se popular em diversas áreas específicas, como sistemas cliente-servidor e servidores e aplicação como o Enterprise JavaBeans.

Bibliotecas compartilhadas

Uma biblioteca compartilhada ou objeto compartilhado é um arquivo que é destinado a ser compartilhado pelos arquivos executáveis e outros arquivos de objeto compartilhados. Os módulos usados por um programa são carregados a partir de objetos compartilhados na memória em tempo de carregamento ou tempo de execução, em vez de serem copiados por um ligador quando ele cria um único arquivo executável monolítico para o programa.

Bibliotecas compartilhadas podem ser ligadas estaticamente, significando que as referências aos módulos de biblioteca são resolvidos e os módulos são alocados na memória quando o arquivo executável for criado. Porém muitas vezes a ligação de bibliotecas compartilhadas é adiada até que elas sejam carregadas.

A maioria dos sistemas operacionais modernos podem ter arquivos de biblioteca compartilhadas do mesmo formato que os arquivos executáveis. Isto oferece duas principais vantagens: primeira, é necessário fazer apenas um carregador para ambos, em vez de dois (possuir o único carregador é considerado vantajoso sua complexidade adicionada). Segundo, possibilita que os executáveis também sejam usados como bibliotecas compartilhadas, se eles possuírem uma tabela de símbolos. Os formatos combinados de bibliotecas executáveis ​​e compartilhadas típicas são ELF e Mach-O (ambos no Unix) e PE (Windows).

Em alguns ambientes mais antigos, como o Windows de 16 bits ou o MPE para os dados (locais) baseados na pilha do HP 3000 apenas era permitido no código da biblioteca compartilhada ou outras restrições significativas foram colocadas no código da biblioteca compartilhada.

O termo biblioteca compartilhada é ambíguo, pois se refere a dois conceitos distintos. O primeiro é o compartilhamento de código localizado no disco por programas não relacionados. O segundo é o compartilhamento de código carregado na memória, quando dois programas executam a mesma página física da RAM, mapeada em diferentes espaços de endereçamento. O segundo caso possui algumas vantagens. Por exemplo, no sistema OpenStep as aplicações tinham geralmente um tamanho pequeno e eram carregadas instantaneamente; a vasta maioria do código estava localizada em bibliotecas já carregadas pelo sistema operacional. Mas existe um custo, pois o código compartilhado deve ser escrito para ser executado em um ambiente multitarefa, o que afeta o desempenho.

Compartilhamento de memória

O código de biblioteca pode ser armazenado em memória por vários processos, bem como no disco. Se memória virtual for usada, os processos executam na mesma página física da RAM que é mapeada nos diferentes espaços de endereço dos processos.

Bibliotecas objeto

Apesar da ligação dinâmica ter sido desenvolvida na década de 1960, somente no final da década de 1980 a tecnologia atingiu o consumidor final. Durante a década de 1990 já estava disponível na maioria dos sistemas operacionais. Durante o mesmo período a programação orientada a objeto tornou-se cada vez mais significativa no desenvolvimento de software. POO em tempo de execução requer informações adicionais que bibliotecas tradicionais não fornecem. Além dos nomes e dos pontos de entrada da biblioteca, também requerem uma lista de objetos do qual dependem. Como no caso de uma herança, que separa partes de uma definição em diferentes pontos do código. Em um sistema verdadeiramente orientado a objeto, as bibliotecas podem não ser conhecidas em tempo de compilação.

Ainda no mesmo período outra área de desenvolvimento era o conceito de execução remota, em que um computador cliente executaria os serviços de um mainframe. O cliente manteria mensagens para a central a fim de receber pacotes de dados para apresentar. Chamadas de procedimento remoto já eram usadas para essas tarefas, ainda que não houvesse um sistema padrão para tal.

Os dois conceitos logo foram fundidos, produzindo um formato de biblioteca orientada a objeto que pudesse ser executado em qualquer local. Tais sistemas foram denominados bibliotecas objeto, ou objetos distribuídos se suportassem acesso remoto. A Component Object Model da Microsoft é exemplo desse tipo de biblioteca para uso local, e a DCOM para uso remoto.

Por um tempo bibliotecas objeto foram a sensação do mundo da programação, existindo esforços para criar sistemas que pudessem ser executados em diferentes plataformas. Exemplos incluem System Object Model (SOM/DSOM) da IBM, Distributed Objects Everywhere (DOE) da Sun Microsystems, Portable Distributed Objects (PDO) da NeXT, Component Object Model (COM/DCOM) da Microsoft, e diferentes sistemas baseados em CORBA. O que sucedeu foi que o conceito foi caindo em desuso, com exceção da COM da Microsoft e o PDO da NeXT (agora Apple Inc.).

Nomenclatura

• GNU/Linux, Solaris e variantes BSD: os arquivoslibfoo.a elibfoo.so estão localizados em diretórios como/lib,/usr/lib ou/usr/local/lib. Os nomes dos arquivos sempre começam comlib e terminam com.a (arquivo, ligação estática) ou.so (objeto compartilhado, ligação dinâmica), opcionalmente com o número da versão interface, comlibfoo.so.2.
• Mac OS X e superiores: o sistema herda as convenções de bibliotecas estáticas do BSD, e pode usar o estilo.so (mas com o sufixo.dylib).
• Microsoft Windows: arquivos*.LIB são de ligação estática e arquivos*.DLL são de ligação dinâmica. Existem ainda usos específicos de DLL, como por exemplo o*.OCX para bibliotecas de controle OCX. A versão da interface está codificada no arquivo, ou abstraída usando uma interface COM.

Ligações externas

• Como fazer bibliotecas de programas em Linux (em inglês)
• Carregamaneto e ligação dinâmica (em inglês)
• Como criar bibliotecas de programas (em inglês)