Problemas de link (VC6)

Question

Abri um espaço de trabalho antigo que é uma biblioteca e seu equipamento de teste.Costumava funcionar bem, mas agora não funciona e versões mais antigas do código também não funcionam com os mesmos erros.Tentei recriar o projeto e isso também causa os mesmos erros.Nada parece fora de ordem nas configurações do projeto e o código gerado funciona no aplicativo principal.

Eu removi a maioria dos arquivos e reduzi ao mínimo para gerar o erro.Infelizmente não posso postar o projeto porque ele é usado no código de produção.

O erro do vinculador LNK2001 que recebo geralmente significa que deixei uma biblioteca ou esqueci de implementar uma função virtual.No entanto, isso faz parte da biblioteca de modelos padrão - e é um cabeçalho.

O código listado como tendo o problema em IOCompletionPort.obj na verdade não usa std::string diretamente, mas chama uma classe que faz: Comms::Exception aceita um std::string e o valor de GetLastError ou WSAGetLastError.

A função mencionada no erro (GetMessage) é implementado, mas é uma função virtual para que outras classes possam substituí-la se necessário.No entanto, parece que o compilador o criou como uma versão Ansi, mas não consigo encontrar nenhuma opção nas configurações que controle isso.Suspeito que esse possa ser o problema, mas como há muito poucas opções para a biblioteca, não tenho como saber com certeza.No entanto, ambos os projetos especificam _MBCS nas opções do compilador.

--------------------Configuração:TestComms - Depuração Win32 -------------------- Vinculando...Comms.lib (iocicliondingport.obj):erro LNK2001:símbolo externo não resolvido "público:Classe virtual std :: Basic_string, classe std :: alocator> __thiscal comunics :: Exception :: getMessagea (void) const "(? getMessagea@excepção@comms@@ube? @@ v? $ Alocator@d@2 @@ std @@ xz) Debug/testComms.EXE:erro fatal LNK1120:1 Externo não resolvido Erro em execução de link.exe.

TestComms.exe - 2 erro(s), 0 aviso(s)

Alguma sugestão?Perdi a maior parte da manhã com isso e não quero perder a maior parte da tarde também.

Answer 1

Uma possibilidade reside na "manipulação de nomes" ANSI/Unicode do Win32, que transforma o símbolo GetMessage em qualquer um GetMessageA ou GetMessageW.Existem três possibilidades:

1. Windows.h não foi carregado, então GetMessage fica GetMessage

2. Windows.h foi carregado com símbolos definidos para ANSI, então GetMessage torna-se GetMessageA

3. Windows.h foi carregado com símbolos definidos para Unicode, então GetMessage torna-se GetMessageW

Se você compilou dois arquivos diferentes de maneiras que acionam dois cenários diferentes, você receberá um erro de vinculador.A mensagem de erro indica que o Comms::Exception class foi uma instância do nº 2 acima - talvez seja usado em algum lugar onde o windows.h não foi carregado?

Outras coisas que eu faria no seu lugar, apenas por uma questão de rotina:

1) Certifique-se de que meus caminhos de inclusão e biblioteca não contenham nada que eu não esteja esperando.

2) Faça uma "limpeza de compilação" e verifique-a manualmente, excluindo quaisquer arquivos de objeto extras, se necessário.

3) Certifique-se de que não haja caminhos codificados nas instruções include que não signifiquem o que significavam quando o projeto foi originalmente reconstruído.

EDITAR:Brigando com a formatação :(

Answer 2

@Curto:Acho que você chegou mais perto.Não testei isso, mas acho que dei a resposta na minha pergunta original.

Obter mensagem é uma definição no Windows.h envolvida em um bloco ifndef para alternar entre Ansi (GetMessageA) e Unicode (GetMessageW).

Answer 3

Supondo que você não tenha mexido nas configurações do projeto, excluindo algo que não deveria ter (que é onde eu esperaria que dependências externas como User32.lib estivessem):

Verifique as ferramentas | Opções | Diretórios | Bibliotecas (passando da memória aqui) e garante que você não esteja perdendo os diretórios da Lib da variedade de todos os jardins comuns (novamente, sem o VC6 na minha frente, não posso lhe dizer o que são)

Answer 4

Este é um problema geral com a forma como a Microsoft lidou com o ANSI vs.APIs Unicode.Como todos (ou praticamente todos) são feitos definindo macros para os nomes de funções que resolvem as versões 'A' ou 'W' dos nomes de funções, você não pode ter com segurança um identificador em seu namespace/class/struct/enum/ função que corresponde a um nome de API do Windows.

As macros windows.h são executadas de maneira grosseira em todos os outros namespaces.

Answer 5

windows.h é declarado na parte superior de IOCompletionPort.h como uma inclusão - eu estava cansado de ver 7 linhas apenas para incluir 1 arquivo, então envolvi seu próprio arquivo e o incluí.Isso também contém algumas #defines adicionais (ou seja, ULONG_PTR), pois nosso aplicativo principal não será compilado com o SDK da plataforma instalado:-(

1. Isso está confirmado.Nada está fora do lugar.
2. Eu fiz isso - excluí os diretórios de construção
3. Eu nunca uso caminhos codificados.