error 126 loading external

    Aug 11 2015 | 8:53 am
    I have created an external, working fine in Max for Live on Mac and on the older Windows computer I compiled it on, but on other windows machines I have: error 126 loading external
    From the forum, it seems there's may eb a problem with dll laoding libraries?
    It was also created in max 6.1 sdk and the loaded into max 7.05.
    any help on this would be really appreciated!

    • Aug 11 2015 | 9:22 am
      a quick update, I compiled the externals on windows 7. I just tested compiling simplemsp~ in both max sdk 6.1 and 7.0.3 when loaded on a windows 8 machine, neither work. The same error appears - (126 loading external)
    • Aug 12 2015 | 8:57 pm
      I spent the morning hunched over no fewer than 3 computers with @Venetian, and we got this worked out. For future reference, here are a few important things to check for developers working in C++, particularly if you're using the C++(11/14) STL.
      1. Be sure to define the preprocessor macro MAXAPI_USE_MSCRT before including "ext.h" (if you're lazy or superstitious, just add it to the Preprocessor section of the project properties window). This will ensure that Max doesn't try (and fail) to link to the backward-compatible, but essentially outdated "maxcrt.lib" (which doesn't provide a lot of C++ features).
      2. If you don't want the users of your externals to require Microsoft's C++ Redistributable Package for the compiler you're using, compile your objects statically with the \MT flag. Yes, your objects will be unnecessarily larger, but what's a few KB compared to failure to load due to missing dependencies?
      3. If you are including , make sure that your function calls to acosh(), asinh(), atanh(), expm1(), exp2(), log2(), round() and trunc() are properly namespaced with std:: .
      I think that's what we learned today, hope this helps someone tomorrow...
    • Aug 14 2015 | 4:12 pm
      Thanks very much Jeremy!
      to recap what's said above: The inital error 126 was because I compiled an /MDd build (dynamic use of C runtime library) and in debug. The computer I tested on didn't have this. To get around these, you can statically link in the C runtime library, using Multi-threaded build (/MT), and /MTd or /MDd for debug versions.
      1. If you use C++11, you won't want to use Cycling's build of the MicroSoft RunTime library, so in Visual Studio, Property Pages->Preprocessor (for the main external) set a flag "MAXAPI_USE_MSCRT" and hit apply/okay so every file uses this flag.
      2. In Linker, you should delete libcmt.lib from being ignored - as you would want these two libcmt.lib and libcmtd.lib
      3. For C++ code, in C/C++->advanced, you would compile as C++ for all bar the .c files.
      If you get an Error 127 you could try building with Max 6 sdk. As above uses of round(), trunc(), atanh() etc should be calling the std:: library versions.
    • Aug 14 2015 | 4:15 pm
      I need to correct your final point. The Max 6 vs. Max 7 SDK makes no difference. The difference was that your Max 6 SDK project didn't link to the jitlib.lib, whereas your Max 7 SDK project did. If you link to the jitlib.lib (with whichever SDK), you will need to explicitly use the std:: namespace for those functions, but you should be using namespace std anyway! :-)
    • Dec 09 2015 | 12:21 pm
      great info Jeremy, thanks alot
    • Feb 03 2016 | 3:32 pm
      Jeremy, you are my Max hero
    • Feb 03 2016 | 4:39 pm
      For posterity though, I tried adding MAXAPI_USE_MSCRT to my preprocessor (I'm superstitious), and this caused this particular problem to mutate into an error 193--external not built for Windows. However, making sure to define MAXAPI_USE_MSCRT before importing ext.h seems to have fixed things.
    • Dec 15 2016 | 8:02 am
      Hey, I'm not super techy, so if you could explain how you fixed this in simple terms that would be great. I tried downloading beat~, pitch~, and segment~, and they all get the same error 126 message.
    • Mar 18 2019 | 5:53 pm
      I followed Jeremy's and Venetian's directions but am now getting the error message: Error 1 error LNK2005: sprintf already defined in MaxAPI.lib(MaxAPI.dll) L:\Code\DSP\platform\MaxMSP\audio\elvis3~\LIBCMTD.lib(sprintf.obj)
      Thanks for any suggestions, Sukandar
      p.s. also, judging by how often this problem shows up on the forum, it would be cool if C74 could address this "error 126" issue in the developer documentation. I just downloaded the latest 8.x SDK and MaxAPI.pdf still has a timestamp from 2015.
    • Mar 18 2019 | 6:58 pm
      good luck!
      Im guessing here but
      Sprintf is a C function? Us that called by your external? How are the includes looking?
    • Mar 18 2019 | 7:21 pm
      thanks for the reply, Venetian
      yes, sprintf() is used not by anything particular to my code, but by the _assist() function that I inherited from the example code
      I include these: #include "ext.h" #include "ext_buffer.h" #include "ext_obex.h" #include "z_dsp.h"
    • Mar 18 2019 | 7:55 pm
      You could have a look at Max Devkit?
      It uses Cmake to build three example projects that compile c++ externals. When I returned to my project recently Iysed that and found it very good.
    • Mar 19 2019 | 1:35 pm
      thanks, I'll have a look I should clarify though that I'm not actually trying to get C++ working. I'm doing plain old C here. I get both the error 126 + a message that MSVCR120D.dll is missing
    • Apr 13 2019 | 3:55 pm
      Hello everyone I also had similar problems and many 'errors 126 loading external' when i tried to play application on another computer, and i really tried to follow every step you wrote up there, but i am feeling myself like i have lack of knowledge to follow all. Some parts i don't even know how to do and what they mean. Is there any chance to someone make video about all this steps from above? It would be really awesome, i guess it would be easier to follow these instructions to me and people who are still new in Max as i am. Sorry if i'm asking for too much, i would just really appreciate if it would exist Thank you
    • Apr 13 2019 | 4:01 pm
      you buult an external for a different windows machine? our notes above relate to linking against static vs dynamic libraries, could you find these in visual studio’s build settings?
    • Apr 14 2019 | 5:10 pm
      Hi Venetian, thanks for reply, I built application on my windows 10 machine and tried to open it on another windows 10 machine, but then i have few errors which are 'error 126 loading external'. I tried to include manually inside of build script (application) all of the files i used inside of patch, but again same errors appear when i try to play it on another windows device. I found in visual studio settings your 1. and 2. step and i changed everything as you mentioned above, instead of 3. step which i really didn't understand. But however, same errors with externals appear even after changing settings. What am i doing wrong?
    • Apr 15 2019 | 10:23 am
      @Lazmih I wonder if you could run through what you're doing in detail? Presumably compiling an external you've written on windows and moving to another machine? Is it C or C++? I would suggest separating the parts. Try compiling MySimpleMax external on your machine and move this. If this is working, we know that the settings there are working for you. a couple of points from Jeremy, maybe he has something to say here? 2. If you don't want the users of your externals to require Microsoft's C++ Redistributable Package for the compiler you're using, compile your objects statically with the \MT flag. Yes, your objects will be unnecessarily larger, but what's a few KB compared to failure to load due to missing dependencies? This seems a bit complicated to me but is to do with static vs dynamic linking for Windows. Are you using C++? If so, what about my max-dev-kit suggestion. Tim Place wrote something on that. It seems that it's a very easy way to compile an external and is a Cycling74 official(ish) release.
      3. If you are including , make sure that your function calls to acosh(), asinh(), atanh(), expm1(), exp2(), log2(), round() and trunc() are properly namespaced with std:: . This is a bit of a weird one. for some reason, there are other functions called round and trunc that aren't std::round. Try building an external without any math functions first and then add these in.
    • Apr 15 2019 | 11:02 am
      I'd be interested to hear from Cycling74 people on this, but I really like the new max-dev-kit way of doing externals:
      (there's a nice way to build a project with CMake and perhaps it will take care of some of these things)
      how does this relate to the older Max-SDK?
    • Jan 13 2020 | 2:00 pm
      Hey ! Sorry to add up something after all this time. Though I have the same problem and I'm quite in a rush. I've given a quick try to max-devkit but Visual Studio can't compile and I'm sure I will spend a lot of time (again) to make it work. So I use the Max SDK and I get the error error 126 loading external
      So I want to use the sndfile library and I tried to use both MDd and MTd options, added MAXAPI_USE_MSCRT in my preprocessor options, deleted all the calls to round and all that functions and deleted libcmt.lib from being ignored. I still get the error.
      What can I do next?
    • Jan 14 2020 | 3:58 pm
      Are you writing C++ code? Is the standard library involved? eg are you calling any functions such as acosh(), asinh(), atanh(), expm1(), exp2(), log2(), round() and trunc() these could be problematic (does namespacing such as std::trunc help?) In practice, I used a workaround, an alternative function for round called rounder() that returns a rounded double. It seems strange to be avoiding std library STL code, but this might help.
    • Jan 19 2020 | 4:44 pm
      My problem I didn't put the .lib file in the resource/support file. I should do a little tuto about all that because there is not much explanations out there about that.
    • Jan 20 2020 | 11:07 am
      I think that max devkit: and min devkit: could be very useful for developing externals, particularly those which want to integrate modern C++.
      I'd be curious to know from Tim Place and the Cycling 74 team: Are these Windows bugs regarding use of STL library: see Jeremy's comment above regarding use of std::round, std::truc and so on, still an issue?
    • Feb 25 2020 | 3:34 pm
      Hi, I've been developing externals with Min-DevKit almost exclusively for the last 3 or 4 years and have not run into problems using std::round() and friends.
      The traditional Max SDK is very exposed to name conflicts and such as it is not C++ savvy with regards to namespacing.
      Cheers! Tim
    • Feb 25 2020 | 3:38 pm
      oh, that sounds promising. So do you think a Windows external built with max-devkit and / or min-devkit would be able to use namespaced std::floor, std::round, std::trunc ect fine these days? Jeremy and I had some problems a few years back when compiled on one machine for Windows and loaded on another.
    • Feb 25 2020 | 4:10 pm
      There could be any number of things going on there. The default for linking with Min-DevKit (and probably Max-DevKit?) is to use static libs for the C/C++ runtime on Windows which should alleviate that type of issue.