Qual é o problema com símbolos indefinidos em uma biblioteca compartilhada ou dylib?

Eu tenho um Makefile para Linux que estou migrando para Darwin. O makefile pega vários arquivos .o e os vincula a um objeto .so compartilhado. Ok, então eu pensei (estou errado sobre isso?) Que o melhor analógico para isso em Darwin é o dylib. Então mudei a bandeira -shared para -dynamiclib.

Agora, o código que estou vinculando ao dylib depende de muitas bibliotecas externas. Quando tento construir o dylib, recebo erros dizendo que há referências indefinidas. Mas o Makefile do Linux não especifica nenhuma das opções -lwhatever ou -L / path / seja o que for na etapa de criação que cria o arquivo .so. Hum? Isso ocorre porque quando você cria um arquivo .so do ELF, por padrão, ele deixa referências externas não resolvidas e, quando a biblioteca compartilhada é carregada,recursivamente carrega bibliotecas compartilhadas das quais a biblioteca compartilhada está sendo carregada? Não seria o caso que, se a biblioteca compartilhada dependesse de um arquivo .a ou .o, você teria que vinculá-los estaticamente à biblioteca compartilhada, caso contrário, não seria possível vincular em tempo de execução? Como você pode se livrar de ter referências indefinidas em uma biblioteca carregada em tempo de execução, a menos que as referências também sejam para bibliotecas dinamicamente carregáveis?

Enfim, se eu especificar

-undefined suppress -flat_namespace

não é necessário adicionar as opções -l e -L ao criar a biblioteca compartilhada. Mas ainda não entendo como isso pode funcionar.

questionAnswers(2)

yourAnswerToTheQuestion