como fazer biblioteca em C usável mas sem o codigo ser aberto??

hitler
(usa openSUSE)

Enviado em 12/07/2017 - 10:24h

criei uma blibioteca e deu muito trabalho, como eu posso fazer uma pessoa usa-la mas sem ver o código???

uilianries
(usa Linux Mint)

Enviado em 12/07/2017 - 10:29h

Distribua apenas os binários e os headers.

gokernel
(usa Linux Mint)

Enviado em 12/07/2017 - 17:15h

Olá !

O modo mais rápido seria assim:

  // será gerado o arquivo( biblioteca.o )

  gcc -c biblioteca.c -Wall

 

Então vc terá apenas de distribuir os arquivos ( biblioteca.o e biblioteca.h ) ...

Foi o que o colega acima( "uilianries" ) quis dizer em poucas palavras, ;)

removido
(usa Nenhuma)

Enviado em 12/07/2017 - 18:08h

Mas não precisa usar uma coisa mais enrolada, como o comando ar, da GNU?

paulo1205
(usa Ubuntu)

Enviado em 12/07/2017 - 19:05h

ar normalmente se usa quando você vai juntar vários objetos (sufixo .o) no mesmo arquivo, por comodidade de os distribuir num arquivo só, em vez de montes de arquivos separados. Um arquivo .a é análogo a um .tar, com a característica adicional que o linker (ld) e outras ferramentas de geração e exame de código objeto (como ranlib, nm, objdump etc.) sabem obter acesso a objetos agregados dentro do .a.

Essa combinação de objetos dentro de um só arquivo em disco é útil para o usuário da biblioteca e para seu desenvolvedor. Imagine, por exemplo, a libc.a. Ela agrega funções bem distintas entre si, como, por exemplo, scanf() e getaddrinfo(). É óbvio que a implementação dessas duas funções, tão distintas entre si, não residem no mesmo arquivo fonte. Nem residem no mesmo arquivo objeto (dentro da minha libc.a, scanf() residem em scanf.o e getaddrinfo(), em getaddrinfo.o). Para quem usa a biblioteca, é vantajoso não ter de referenciar uma quantidade absurda de arquivos .o diferentes na hora de chamar o linker (até porque a ordem em que esses arquivos são chamados também é relevante!). Para quem desenvolve a biblioteca, também é útil, pois, caso haja alguma manutenção a ser feita na biblioteca, pode-se mexer e recompilar apenas as partes relevantes, com uma quantidade pequena de código, o que pode gerar uma considerável economia de tempo.

Dependendo do que se queira fazer, pode ser necessário usar ranlib. E se se quiser distribuir uma biblioteca dinâmica, devem-se usar flags de compilação específicos, como -fpic (ou -fPIC, eu nunca lembro quando é um ou outro) e -shared.

removido
(usa Nenhuma)

Enviado em 12/07/2017 - 23:00h

Estou acostumado em pensar que esses arquivos .o são apenas arquivos do tipo conhecido como "objeto".

Para quem não sabe e está lendo, tem nada a ver com POO.

Devo ter visto linha de comando de compilador arquivos .o nos parâmetros.

Costumava ver arquivos de objeto em linhas de comando de linkedição, não necessariamente nessas ferramentas da GNU, Unix etc.

Arquivos .o ou objetos não eram arquivos de tabelas, constantes, endereços de variáveis convertidos, indicação de chamadas de subrotinas dos outros que são tidos como bibliotecas? Essas chamadas de instruções são resolvidas pela criação de ligações (links) na chamada linkedição.

Arquivos de bibliotecas costumavam ser arquivos com as verdadeiras instruções que são executadas quando o programa estiver pronto.

Um código de uma função que usa a instrução sin(x) criado em formato .o teria apenas as referências do mesmo e algum tipo de indicação de que as instruções de sin(x) devem ser buscadas de algum lugar.

Na verdade fiquei em dúvida.

O arquivo .o estaria mais para uma biblioteca se ele, por exemplo, possuísse uma implementação de sin(x) e tivesse todas as instruções sem depender de alguma outra coisa, como libmat por exemplo.

Não sei. Talvez esse arquivo .o criado pudesse ser encarado como uma biblioteca também.

A dúvida seria mais sobre o que seria um arquivo tipo objeto e uma biblioteca. Talvez eu devesse redefinir os conceitos. Não sei se me expressei bem. Não quis ficar verificando no Google se escrevi alguma coisa inexata principalmente para poder tirar as dúvidas. Faz tempo que não penso nestas coisas.