As opções no arquivo são separadas por espaço em branco . Um caractere de espaço em branco pode ser incluído em uma opção colocando a opção inteira entre aspas simples ou duplas. Qualquer caractere (incluindo uma barra invertida) pode ser incluído prefixando o caractere a ser incluído em uma barra invertida. O próprio arquivo pode conter opções adicionais de @ arquivo ; essas opções serão processadas recursivamente .

–architecture = arquitetura

Versões futuras do ld podem suportar funcionalidades semelhantes para outras famílias de arquitetura.

–format = formato de entrada

Você pode usar esta opção se estiver vinculando arquivos com um formato binário incomum. Você também pode usar -b para alternar formatos explicitamente (ao vincular arquivos de objetos de diferentes formatos), incluindo -b -format-input antes de cada grupo de arquivos de objetos em um formato específico.

O formato padrão é obtido da variável de ambiente “GNUTARGET”.

Você também pode definir o formato de entrada de um script, usando o comando “TARGET”;

–mri-script = MRI-commandfile

-dc

-dp

-P AUDITLIB

–entry = entrada

–export-dynamic

–no-export-dynamic

Se você não usar nenhuma dessas opções (ou a opção –no-export-dynamic para restaurar o comportamento padrão), a tabela de símbolos dinâmicos normalmente conterá apenas os símbolos mencionados por algum objeto dinâmico mencionado no link.

Se você usar ” dlopen ” para carregar um objeto dinâmico que precise se referir aos símbolos definidos pelo programa, em vez de algum outro objeto dinâmico, provavelmente precisará usar esta opção ao vincular o próprio programa.

Você também pode usar a lista dinâmica para controlar quais símbolos devem ser adicionados à tabela de símbolos dinâmicos se o formato de saída suportar. Veja a descrição de –dynamic-list .

Observe que esta opção é específica para portas direcionadas ao ELF. Os destinos do PE oferecem suporte a uma função semelhante para exportar todos os símbolos de uma DLL ou EXE ; veja a descrição de –export-all-symbols abaixo.

–auxiliary = nome

Se você posteriormente vincular um programa a esse objeto de filtro, quando executar o programa, o vinculador dinâmico verá o campo DT_AUXILIARY. Se o vinculador dinâmico resolver qualquer símbolo do objeto de filtro, ele primeiro verificará se há uma definição no nome do objeto compartilhado. Se houver, ele será usado em vez da definição no objeto de filtro. O nome do objeto compartilhado não precisa existir. Assim, o nome do objeto compartilhado pode ser usado para fornecer uma implementação alternativa de certas funções, talvez para depuração ou desempenho específico da máquina.

Esta opção pode ser especificada mais de uma vez. As entradas DT_AUXILIARY serão criadas na ordem em que aparecem na linha de comandos.

–filter = nome

Se você posteriormente vincular um programa a esse objeto de filtro, quando executar o programa, o vinculador dinâmico verá o campo DT_FILTER. O vinculador dinâmico resolverá os símbolos de acordo com a tabela de símbolos do objeto de filtro, como de costume, mas, na verdade, será vinculado às definições encontradas no nome do objeto compartilhado. Assim, o objeto de filtro pode ser usado para selecionar um subconjunto dos símbolos fornecidos pelo nome do objeto.

Alguns vinculadores mais antigos usaram a opção -F em uma cadeia de ferramentas de compilação para especificar o formato do arquivo de objeto para os arquivos de objeto de entrada e saída. O vinculador GNU usa outros mecanismos para esse propósito: as opções -b , –format , –oformat , o comando “TARGET” nos scripts do vinculador e a variável de ambiente “GNUTARGET”. O vinculador GNU ignora a opção -F quando não está criando um objeto compartilhado ELF.

–gpsize = value

-soname = nome

–library = namespec

Em sistemas que suportam bibliotecas compartilhadas, o ld também pode procurar por arquivos que não sejam lib namespec .a . Especificamente, nos sistemas ELF e SunOS , o ld procurará em um diretório uma biblioteca chamada lib namespec .so antes de procurar um chamado lib namespec .a . Por convenção, uma extensão ” .so ” indica uma biblioteca compartilhada. Observe que esse comportamento não se aplica a : filename , que sempre especifica um arquivo chamado filename .

O vinculador pesquisará um arquivo morto apenas uma vez, no local em que ele está especificado na linha de comando. Se o arquivo morto definir um símbolo que não foi definido em algum objeto que apareceu antes do arquivo morto na linha de comando, o vinculador incluirá o (s) arquivo (s) apropriado (s) do arquivo morto. No entanto, um símbolo indefinido em um objeto que aparece mais tarde na linha de comando não fará com que o vinculador procure no arquivo morto novamente.

Consulte a opção – ( para obter uma maneira de forçar o vinculador a pesquisar arquivos várias vezes.

Você pode listar o mesmo arquivo várias vezes na linha de comando.

Esse tipo de pesquisa de arquivo é padrão para os vinculadores Unix. No entanto, se você estiver usando ld no AIX , observe que ele é diferente do comportamento do vinculador do AIX.

–library-path = searchdir

Se searchdir começar com ” = “, o ” = ” será substituído pelo prefixo sysroot , um caminho especificado quando o vinculador estiver configurado.

O conjunto padrão de caminhos pesquisados ​​(sem ser especificado com -L ) depende de qual modo de emulação ld está usando e, em alguns casos, também de como foi configurado no tempo de compilação.

Os caminhos também podem ser especificados em um script de link com o comando “SEARCH_DIR”. Os diretórios especificados dessa maneira são pesquisados ​​no ponto em que o script do vinculador aparece na linha de comando.

Se a opção -m não for usada, a emulação será obtida da variável de ambiente “LDEMULATION”, se isso for definido.

Caso contrário, a emulação padrão depende de como o vinculador foi configurado.

–print-map

• Onde os arquivos de objetos são mapeados na memória.
• Como os símbolos comuns são alocados.
• Todos os membros do arquivo incluídos no link, com uma menção ao símbolo que causou o membro do arquivo.
• Os valores atribuídos aos símbolos.

Nota: símbolos cujos valores são calculados por uma expressão que envolve uma referência a um valor anterior do mesmo símbolo podem não ter o resultado correto exibido no mapa de links. Isso ocorre porque o vinculador descarta resultados intermediários e apenas retém o valor final de uma expressão. Sob tais circunstâncias, o vinculador exibe o valor final entre colchetes. Assim, por exemplo, um script vinculador que contém:

  foo = 1 
 foo = foo * 4 
 foo = foo + 8

produzirá a seguinte saída no mapa de link se a opção -M for usada:

  0x00000001 foo = 0x1 
 [0x0000000c] foo = (foo * 0x4) 
 [0x0000000c] foo = (foo + 0x8)

–nmagic

–omagic

– saída = saída

–emit-relocs

Atualmente, esta opção é suportada apenas nas plataformas ELF.

–relocável

Quando um arquivo de entrada não possui o mesmo formato que o arquivo de saída, a vinculação parcial é suportada apenas se esse arquivo de entrada não contiver realocações. Diferentes formatos de saída podem ter restrições adicionais; por exemplo, alguns formatos baseados em ” a.out ” não oferecem suporte à vinculação parcial a arquivos de entrada em outros formatos.

Esta opção faz a mesma coisa que -i .

–just-symbols = nome do arquivo

Para compatibilidade com outros vinculadores ELF, se a opção -R for seguida por um nome de diretório, em vez de um nome de arquivo, ela será tratada como a opção -rpath .

–strip-all

–strip-debug

–vestígio

–script = scriptfile

–default-script = scriptfile

Essa opção é semelhante à opção –script, exceto que o processamento do script é adiado até depois que o restante da linha de comando foi processado. Isso permite que as opções colocadas após a opção –default-script na linha de comando afetem o comportamento do script do vinculador, o que pode ser importante quando a linha de comando do vinculador não puder ser controlada diretamente pelo usuário. (por exemplo, porque a linha de comando está sendo construída por outra ferramenta, como o gcc ).

–undefined = símbolo

–versão

-V

–discard-all

–discard-locals

Essa opção é útil quando você tem um símbolo indefinido no seu link, mas não sabe de onde vem a referência.

Outras palavras-chave são ignoradas para compatibilidade com Solaris.

–start-group arquivos –end-group

Os arquivos especificados são pesquisados ​​repetidamente até que nenhuma nova referência indefinida seja criada. Normalmente, um arquivo é pesquisado apenas uma vez na ordem em que é especificado na linha de comando. Se um símbolo nesse arquivo for necessário para resolver um símbolo indefinido referido por um objeto em um arquivo que aparece posteriormente na linha de comando, o vinculador não poderá resolver essa referência. Ao agrupar os arquivos, todos eles são pesquisados ​​repetidamente até que todas as referências possíveis sejam resolvidas.

O uso desta opção tem um custo de desempenho significativo. É melhor usá-lo somente quando houver referências circulares inevitáveis ​​entre dois ou mais arquivos.

–no-accept-unknown-input-arch

–não necessário

–no-add-needed

-dy

-call_shared

-dn

-non_shared

-static

The format of the dynamic list is the same as the version node without scope and node name.

–no-check-sections

–no-copy-dt-needed-entries

This option also has an effect on the resolution of symbols in dynamic libraries. With –copy-dt-needed-entries dynamic libraries mentioned on the command line will be recursively searched, following their DT_NEEDED tags to other libraries, to resolve symbols required by the output binary. With the default setting, however, the searching of dynamic libraries that follow it will stop with the dynamic library itself. No DT_NEEDED links will be traversed to resolve symbols.

The format of the table is intentionally simple, so that it may be easily processed by a script if necessary. The symbols are printed out, sorted by name. For each symbol, a list of file names is given. If the symbol is defined, the first file listed is the location of the definition. The remaining files contain references to the symbol.

The –no-define-common option allows decoupling the decision to assign addresses to Common symbols from the choice of the output file type; otherwise a non-Relocatable output type forces assigning addresses to Common symbols. Using –no-define-common allows Common symbols that are referenced from a shared library to be assigned addresses only in the main program. This eliminates the unused duplicate space in the shared library, and also prevents any possible confusion over resolving to the wrong duplicate when there are many dynamic modules with specialized search paths for runtime symbol resolution.

–no-demangle

–dynamic-linker= file

–no-fatal-warnings

If a successfully built fully linked output file does not have a ” .exe ” or ” .dll ” suffix, this option forces the linker to copy the output file to one of the same name with a ” .exe ” suffix. This option is useful when using unmodified Unix makefiles on a Microsoft Windows host, since some versions of Windows won’t run an image unless it ends in a ” .exe ” suffix.

–no-gc-sections

–gc-sections decides which input sections are used by examining symbols and relocations. The section containing the entry symbol and all sections containing symbols undefined on the command-line will be kept, as will sections containing symbols referenced by dynamic objects. Note that when building shared libraries, the linker must assume that any visible symbol is referenced. Once this initial set of sections has been determined, the linker recursively marks as used any section referenced by their relocations. See –entry and –undefined .

This option can be set when doing a partial link (enabled with option -r ). In this case the root of symbols kept must be explicitly specified either by an –entry or –undefined option or by a “ENTRY” command in the linker script.

–no-print-gc-sections

-z defs

-z muldefs

–no-allow-shlib-undefined

O comportamento padrão é relatar erros para quaisquer símbolos indefinidos mencionados em bibliotecas compartilhadas se o vinculador estiver sendo usado para criar um executável, mas permitir isso se o vinculador estiver sendo usado para criar uma biblioteca compartilhada.

Os motivos para permitir referências de símbolo indefinidas em bibliotecas compartilhadas especificadas no momento do link são:

• Uma biblioteca compartilhada especificada no tempo do link pode não ser a mesma que está disponível no tempo de carregamento, portanto, o símbolo pode realmente ser resolvido no tempo de carregamento.
• Existem alguns sistemas operacionais, por exemplo, BeOS e HPPA, nos quais símbolos indefinidos em bibliotecas compartilhadas são normais.

O kernel do BeOS, por exemplo, corrige bibliotecas compartilhadas no tempo de carregamento para selecionar a função mais apropriada para a arquitetura atual. Isso é usado, por exemplo, para selecionar dinamicamente uma função memset apropriada.

–pic-executável

–no-relax

Em algumas plataformas, a opção –relax realiza otimizações globais específicas de destino que se tornam possíveis quando o vinculador resolve o endereçamento no programa, como relaxar os modos de endereço, sintetizar novas instruções, selecionar versão mais curta das instruções atuais e combinar valores constantes.

Em algumas plataformas, essas otimizações globais no tempo do link podem impossibilitar a depuração simbólica do executável resultante. Esse é o caso da família de processadores Matsushita MN10200 e MN10300.

Nas plataformas em que isso não é suportado, –relax é aceito, mas ignorado.

Nas plataformas em que –relax é aceito, a opção –no-relax pode ser usada para desativar o recurso.

–retain-symbols-file não descarta símbolos indefinidos ou símbolos necessários para realocações.

Você pode especificar –retain-symbols-file uma vez na linha de comando. Ele substitui -s e -S .

A opção -rpath também pode ser usada no SunOS. Por padrão, no SunOS, o vinculador formará um patch de pesquisa em tempo de execução com todas as opções -L fornecidas. Se uma opção -rpath for usada, o caminho de pesquisa em tempo de execução será formado exclusivamente usando as opções -rpath , ignorando as opções -L . Isso pode ser útil ao usar o gcc , que adiciona muitas opções -L que podem estar nos sistemas de arquivos montados pelo NFS.

Para compatibilidade com outros vinculadores ELF, se a opção -R for seguida por um nome de diretório, em vez de um nome de arquivo, ela será tratada como a opção -rpath .

Quando o vinculador encontra essa dependência ao criar um link não compartilhado e não realocável, ele tenta automaticamente localizar a biblioteca compartilhada necessária e incluí-la no link, se não for incluído explicitamente. Nesse caso, a opção -rpath-link especifica o primeiro conjunto de diretórios a serem pesquisados. A opção -rpath-link pode especificar uma sequência de nomes de diretório, especificando uma lista de nomes separados por dois pontos ou aparecendo várias vezes.

Essa opção deve ser usada com cautela, pois substitui o caminho de pesquisa que pode ter sido compilado em uma biblioteca compartilhada. Nesse caso, é possível usar involuntariamente um caminho de pesquisa diferente do que o vinculador de tempo de execução faria.

O vinculador usa os seguintes caminhos de pesquisa para localizar as bibliotecas compartilhadas necessárias:

1. Todos os diretórios especificados pelas opções -rpath-link .
2. Qualquer diretório especificado pelas opções -rpath . A diferença entre -rpath e -rpath-link é que os diretórios especificados pelas opções -rpath são incluídos no executável e usados ​​no tempo de execução, enquanto a opção -rpath-link é eficaz apenas no momento do link. A pesquisa de -rpath dessa maneira é suportada apenas por vinculadores nativos e cruzadores que foram configurados com a opção –with-sysroot .
3. Em um sistema ELF, para vinculadores nativos, se as opções -rpath e -rpath-link não foram usadas, procure o conteúdo da variável de ambiente “LD_RUN_PATH”.
4. No SunOS, se a opção -rpath não foi usada, procure os diretórios especificados usando as opções -L .
5. Para um vinculador nativo, procure o conteúdo da variável de ambiente “LD_LIBRARY_PATH”.
6. Para um vinculador ELF nativo, os diretórios em “DT_RUNPATH” ou “DT_RPATH” de uma biblioteca compartilhada são pesquisados ​​em busca de bibliotecas compartilhadas necessárias. As entradas “DT_RPATH” serão ignoradas se existirem entradas “DT_RUNPATH”.
7. Os diretórios padrão, normalmente / lib e / usr / lib .
8. Para um vinculador nativo em um sistema ELF, se o arquivo /etc/ld.so.conf existir, a lista de diretórios encontrados nesse arquivo.

Se a biblioteca compartilhada necessária não for encontrada, o vinculador emitirá um aviso e continuará com o link.

-Bshareable

–sort-common = ascendente

–sort-common = descendente

Por exemplo, no SunOS, ld combina entradas duplicadas na tabela de cadeias de símbolos. Isso pode reduzir o tamanho de um arquivo de saída com informações completas de depuração em mais de 30%. Infelizmente, o programa SunOS dbx não consegue ler o programa resultante (embora o gdb não tenha problemas). A opção –traditional-format diz ao ld para não combinar entradas duplicadas.

-Tdata = org

-Ttext = org

Normalmente, o vinculador gera uma mensagem de erro para cada símbolo não resolvido relatado, mas a opção –warn-unresolved-symbols pode mudar isso para um aviso.

–verbose [ = NÚMERO]

Existem três tipos de símbolos globais, ilustrados aqui pelos exemplos C:

  int i = 1;

Uma definição, que vai na seção de dados inicializados do arquivo de saída.

  extern int i;

Uma referência indefinida, que não aloca espaço. Deve haver uma definição ou um símbolo comum para a variável em algum lugar.

  int i;

Um símbolo comum. Se houver apenas (um ou mais) símbolos comuns para uma variável, ela entrará na área de dados não inicializados do arquivo de saída. O vinculador mescla vários símbolos comuns para a mesma variável em um único símbolo. Se eles são de tamanhos diferentes, ele escolhe o maior tamanho. O vinculador transforma um símbolo comum em uma declaração, se houver uma definição da mesma variável.

A opção –warn-common pode produzir cinco tipos de avisos. Cada aviso consiste em um par de linhas: o primeiro descreve o símbolo recém-encontrado e o segundo descreve o símbolo anterior encontrado com o mesmo nome. Um ou os dois símbolos serão um símbolo comum.

1. Transformando um símbolo comum em uma referência, porque já existe uma definição para o símbolo.

  <file> (<section>): aviso: comum de `<symbol> ' 
 substituído por definição 
 <file> (<section>): aviso: definido aqui

2. Transformando um símbolo comum em uma referência, porque é encontrada uma definição posterior para o símbolo. É o mesmo que no caso anterior, exceto que os símbolos são encontrados em uma ordem diferente.

  <file> (<section>): aviso: definição de `<symbol> '
     substituindo comum
 <file> (<section>): aviso: comum está aqui

3. Mesclando um símbolo comum com um símbolo comum anterior do mesmo tamanho.

  <file> (<section>): aviso: vários arquivos comuns
     de `` <symbol> ''
 <file> (<section>): aviso: o anterior comum está aqui

4. Mesclando um símbolo comum com um símbolo comum maior anterior.

  <file> (<section>): aviso: comum de `<symbol> '
     substituído por maior comum
 <file> (<section>): aviso: maior comum está aqui

5. Mesclando um símbolo comum com um símbolo comum menor anterior. É o mesmo que no caso anterior, exceto que os símbolos são encontrados em uma ordem diferente.

  <file> (<section>): aviso: comum de `<symbol> '
     substituindo comum menor
 <file> (<section>): aviso: menor comum está aqui

Duas notas ao usar esta opção no gcc : Primeiro, o gcc não sabe sobre essa opção, então você precisa usar -Wl, -whole-archive . Segundo, não esqueça de usar -Wl, -no-whole-archive após sua lista de arquivos, porque o gcc adicionará sua própria lista de arquivos ao seu link e você pode não querer que esse sinalizador os afete também.

Isso pode ser usado para fornecer um wrapper para uma função do sistema. A função de wrapper deve ser chamada ” __wrap_symbol “. Se desejar chamar a função do sistema, deve chamar ” __real_symbol “.

Aqui está um exemplo trivial:

  vazio *
 __wrap_malloc (size_t c)
 {
   printf ("malloc chamado com% zu \ n", c);
   return __real_malloc (c);
 }

Se você vincular outro código a esse arquivo usando –wrap malloc , todas as chamadas para ” malloc ” chamarão a função ” __wrap_malloc “. A chamada para ” __real_malloc ” em ” __wrap_malloc ” chamará a função ” malloc ” real.

Você também pode fornecer uma função ” __real_malloc “, para que os links sem a opção –wrap sejam bem-sucedidos. Se você fizer isso, não deverá colocar a definição de ” __real_malloc ” no mesmo arquivo que ” __wrap_malloc “; se o fizer, o assembler poderá resolver a chamada antes que o vinculador tenha a chance de encapsulá-la no ” malloc “.

–disable-new-dtags

Outro efeito do comutador é definir o tamanho da tabela de hash padrão como 1021, o que economiza memória à custa do aumento do tempo de execução do vinculador. Isso não é feito, no entanto, se a opção –hash-size tiver sido usada.

A opção –reduce-overheads-overheads também pode ser usada para permitir outras compensações em versões futuras do vinculador.

–build-id = estilo

Os estilos ” md5 ” e ” sha1 ” produzem um identificador que é sempre o mesmo em um arquivo de saída idêntico, mas será exclusivo entre todos os arquivos de saída não-idênticos. Não se destina a ser comparado como uma soma de verificação para o conteúdo do arquivo. Um arquivo vinculado pode ser alterado posteriormente por outras ferramentas, mas a sequência de bits do ID de construção que identifica o arquivo vinculado original não muda.

Passar ” none ” para o estilo desabilita a configuração de qualquer opção ” –build-id ” anteriormente na linha de comando.

–disable-long-section-names

–disable-stdcall-fixup

–no-líder-sublinhado

– reserva de pilha , confirmar

Note: use of the ‘auto-import’ extension will also cause read only data which would normally be placed into the .rdata section to be placed into the .data section instead. This is to work around a problem with consts that is described at the cygwin website .

Using ‘auto-import’ generally will ‘just work’, but sometimes you may see this message:

 "variable '<var>' can't be auto-imported. 
Please read the documentation for 
ld's "--enable-auto-import" for details."

This message occurs when some (sub)expression accesses an address ultimately given by the sum of two constants (Win32 import tables only allow one). Instances where this may occur include accesses to member fields of struct variables imported from a DLL, as well as using a constant index into an array variable imported from a DLL. Any multiword variable ( array s, struct s, long long , etc) may trigger this error condition. However, regardless of the exact data type of the offending exported variable, ld will always detect it, issue the warning, and exit.

There are several ways to address this difficulty, regardless of the data type of the exported variable:

One way is to use –enable-runtime-pseudo-reloc switch. This leaves the task of adjusting references in your client code for runtime environment, so this method works only when runtime environment supports this feature.

A second solution is to force one of the ‘constants’ to be a variable — that is, unknown and un-optimizable at compile time. For arrays, there are two possibilities: a) make the indexee (the array’s address) a variable, or b) make the ‘constant’ index a variable. Portanto:

 extern type extern_array[]; 
extern_array[1] --> 
{ volatile type *t=extern_array; t[1] }

ou

 extern type extern_array[]; 
extern_array[1] --> 
{ volatile int t=1; extern_array[t] } 

For struct s (and most other multiword data types) the only option is to make the struct itself (or the long long , etc.) variable:

 extern struct s extern_struct; 
extern_struct.field --> 
{ volatile struct s *t=&extern_struct; t->field }

ou

 extern long long extern_ll; 
extern_ll --> 
{ volatile long long * local_ll=&extern_ll; *local_ll }

A third method of dealing with this difficulty is to abandon ‘auto-import’ for the offending symbol and mark it with ” __declspec(dllimport) “. However, in practice that requires using compile-time #defines to indicate whether you are building a DLL, building client code that will link to the DLL, or merely building/linking to a static library. In making the choice between the various methods of resolving the ‘direct address with constant offset’ problem, you should consider typical real-world usage:

Original:

foo.h :

 extern int arr[];

foo.c :

 #include "foo.h"
void main(int argc, char **argv){
  printf("%d\n",arr[1]);
 }

Solução 1:

foo.h :

 extern int arr[];

foo.c :

 #include "foo.h"
void main(int argc, char **argv){
  printf("%d\n",arr[1]);
 }

Solução 2:

foo.h :

 extern int arr[];

foo.c :

 #include "foo.h"
void main(int argc, char **argv){
  /* This workaround is for win32 
     and cygwin; do not "optimize" */
  volatile int *parr = arr;
  printf("%d\n",parr[1]);
 }

A fourth way to avoid this problem is to re-code your library to use a functional interface rather than a data interface for the offending variables (eg, set_foo() and get_foo() accessory functions). [This option is specific to the i386 PE targeted port of the linker]

–stack reserve , commit

–subsystem which : major

–subsystem which : major . menor

The following options set flags in the “DllCharacteristics” field of the PE file header: [These options are specific to PE targeted ports of the linker]

The –no-merge-exidx-entries switch disables the merging of adjacent exidx entries in frame unwind info.