Ok, thankfully this ended up being a fairly simple fix. This post allowed me to figure out the problem:
https://stackoverflow.com/questions/538134/exporting-functions-from-a-dll-with-dllexport StackOverFlow to the rescue again. Basically, the library was linking ok, but the package loaded was getting exported using the name "_RexxGetPackage" rather than "RexxGetPackage". The source of the error was the RexxEntry modifier on the macro that generated the loader. For 64-bit, this is a nop, for 32-bit, it actually undid some of the things generated by the REXXEXPORT. If a .def was used with that export name, it generated what we wanted. Removing the RexxEntry from the specification gives something that works for 32- and 64-bit. This is all a non-factor for other platforms. Rick On Mon, Dec 17, 2018 at 9:56 AM Rick McGuire <object.r...@gmail.com> wrote: > is the build machine on a different version of the compiler? I'm able to > get the failure using the same version as Rony. I think I might be closing > in on a fix, but so far, my fix attempts have only worked on one of the two > builds. > > Rick > > On Mon, Dec 17, 2018 at 9:48 AM Erich Steinböck < > erich.steinbo...@gmail.com> wrote: > >> Rony, our build machine successfully builds r11627 for 32-bit Windows. >> (The Jenkins job itself fails, but for a different reason). >> >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
