Skip to main content
gamedev.net
🔒 Locked

Dll hell

Started by Codejoy 5 replies 900+ views
Original Post
Codejoy
Codejoy
Okay, so I have a dll thats an api i created... i want to create another dll that wraps this api. So i do this, and the calls i make to the other dll i get linker errors: Linking... Creating library Debug/Abfa4NSFF.lib and object Debug/Abfa4NSFF.exp ABFA4NSff.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) struct ABFAParameters * __cdecl GetDefaultABFAInfo(int,int)" (__imp_?GetDefaultABFAInfo@@YAPAUABFAParameters@@HH@Z) ABFA4NSff.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl LoadABFADefaults(char *,char *)" (__imp_?LoadABFADefaults@@YAXPAD0@Z) ABFA4NSff.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl ABFAInitialize(void)" (__imp_?ABFAInitialize@@YAXXZ) ABFA4NSff.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl ABFATerminate(void)" (__imp_?ABFATerminate@@YAXXZ) ABFA4NSff.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl ABFAEngine1(struct ABFAParameters *)" (__imp_?ABFAEngine1@@YAXPAUABFAParameters@@@Z) Debug/Abfa4NSFF.dll : fatal error LNK1120: 5 unresolved externals Error executing link.exe. Do i make another test project, that ISNT a dll, and that makes the same calls to the dll i want to wrap, and it compiles fine. I assume im missing something small and stupid but its been so long since ive trudged in the trenchs of dll''s i cannot remember what it is. My project settings is set to link with the .lib for the dll that im trying to wrap. and im including the .h file for the function prototypes of the dll im trying to wrap. So to me everything is as it is supposed ot but its not working. What else do i need? I am using the __declspec(dllexport) in both dll''s any ideas would be great, thanks -Shane
neurokaotix
neurokaotix
Alright, let me try to get the facts straight...

  • You wrote an API and stuck it in a DLL
  • You want a dll that will wrap this API from the DLL
  • When you try to compile the wrapper DLL, it gives you the link errors
  • When you make a regular .exe, you don''t get the link errors

    If all those facts are correct I would have to think that the wrapper DLL doesn''t have access to the code you''re trying to link (e.g. you didn''t link the myAPI.lib or whatever that accompanies the dll).

    If that''s not the case, could you give some more information?

    James Simmons
    MindEngine Development
    http://medev.sourceforge.net
    • raven_soul
    raven_soul
    You must also place the DLL that was created in the main directory of the project, or put it in your WINDOWS/system (or system32 if you''re on NT/ME/2k/XP).
    Codejoy
    Codejoy
    Well i did place it in the directory, and yes im linking the lib in there too.

    Now i know there is a way t o set up paths to headers and lib files in VC++ 6.0 (What im using) well i dont do this and just make sure the lib and .h files are in the project source folder. And that to me is the proper thinking because the exe (that works) project space doesnt have the directories set to the headers or the lib file either (you know tools options directories).

    Id love to include more info on this, but thats the thing i dont know what else to say, its a small simple test project (im glad i decided to do a small test to flesh out these crappy errors) and so there isnt really much else i can think of thats going on, i know there is something going on obviosuly but what i dont know...Im sure its something really small and stupid too ugh.

    Dll''s blah
    -Shane
    SabreMan
    SabreMan
    quote:
    Original post by raven_soul
    You must also place the DLL that was created in the main directory of the project, or put it in your WINDOWS/system (or system32 if you''re on NT/ME/2k/XP).

    Nonsense. The whole point of a dynamic link library is that it doesn''t have to be present at static link time.
    quote:
    Original post by Codejoy
    Now i know there is a way t o set up paths to headers and lib files in VC++ 6.0 (What im using) well i dont do this and just make sure the lib and .h files are in the project source folder. And that to me is the proper thinking

    The only things which should really be under the directory tree for your project are those things which are exclusive to the project. If you are including or linking against things which are used in multiple projects, then they should really be set up to reflect that.
    quote:

    because the exe (that works) project space doesnt have the directories set to the headers or the lib file either (you know tools options directories).

    Huh? It sounds to me like you are randomly dropping things into your project in case it suddenly makes it all work. You need to take a step back and think about exactly what you are trying to achieve.
    quote:

    Id love to include more info on this, but thats the thing i dont know what else to say

    Then you''re unlikely to get an answer.
    Codejoy
    Codejoy
    Well I am not ramdomly dropping stuff into the project space.

    I have created two projects:
    One a DLL
    the other just a console exe

    They both work with a dll that i have the .lib and the .h for.

    The console exe one works fine when I do this, i goto project-settings->link and include the .lib for the dll im trying to link with.

    I do the same with the dll project, and i get the linker errors full of unresolved errors on all the functions from the dll im trying to link with. Ic all the same dll functions from the .exe program and it works fine, the dll program doesn''t.

    I have no clue why im getting these linker errors...


    So im not randomly tried stuff until i posted here and got the suggestions, since I am out of ideas of course ill randomly try things (one at a time) so i can see what will make it work if anything.

    Thank you,
    Shane

    Topic Locked

    This topic has been locked by a moderator. New replies are not allowed.

    Sign in to reply to this topic.