Member Avatar for Skeen

So I'm working on this game, and I've been using "glaux.h" to load my textures, however I'm interrested in using JPEG's, so I found an example to do this on: , however, when I compile it (after fixing the errors), then I get this, on the linking state, any help to get?

(Don't know if I'm supposed to go to the DEVc++ forums, og the GCG?)

variable '_iob' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. 
  .drectve `-defaultlib:uuid.lib ' unrecognized 
  .drectve `-defaultlib:uuid.lib ' unrecognized 
  .drectve `-defaultlib:LIBC ' unrecognized 
  .drectve `-defaultlib:OLDNAMES ' unrecognized 
  .drectve `-defaultlib:uuid.lib ' unrecognized 
  .drectve `-defaultlib:uuid.lib ' unrecognized 
  .drectve `-defaultlib:LIBC ' unrecognized 
  .drectve `-defaultlib:OLDNAMES ' unrecognized 
  .drectve `-defaultlib:uuid.lib ' unrecognized 
  .drectve `-defaultlib:uuid.lib ' unrecognized 
... For all eternaty
  resolving __iob by linking to __imp___iob (auto-import) 
... More .drectve
then:
  [Linker error] undefined reference to `_nm___iob' 
  ld returned 1 exit status

Easy Fixable, or should I simply change and use OpenIL (DevIL)?

Edited by Skeen because: n/a
  • 1 Contributor
  • 1 Reply
  • 132 Views
  • 7 Hours Discussion Span
  • Latest Post Latest Post by Skeen

Dani AI

Generated

The build failure is almost certainly a toolchain/runtime mismatch: the GNU linker is seeing Windows/MSVC-style import directives and data-symbol imports that do not match the local MinGW runtime. That produces lots of “embedded directive” warnings and then unresolved CRT/data-symbols at link time. This is a compatibility problem, not a bug in the JPEG loader code itself.

Practical options, ordered by how easy they are to try:

  • Quick workaround: allow automatic data-symbol imports in the GNU linker by adding the flag --enable-auto-import. With g++ that looks like:

    g++ ... -Wl,--enable-auto-import

    This can unblock the link but is a hack that can hide real ABI/runtime differences.

  • Create a MinGW-compatible import library from any existing Windows DLL and use that instead of an MSVC .lib. Example utilities and commands commonly used:

    pexports mylib.dll > mylib.def
dlltool -D mylib.dll -d mylib.def -l libmylib.a

  • Best long-term fix: rebuild the JPEG/image library with the same compiler/toolchain used for the rest of the project (MinGW or MinGW-w64). That produces import libs that match the GNU toolchain and removes the embedded-directive warnings.

If changing the toolchain is acceptable, either switch to MSVC and use MSVC-built libs, or move to a MinGW-w64/MSYS2 environment and install MinGW-native packages for libjpeg. For small projects, a header-only loader (single-file JPEG reader) avoids external linking altogether. Checklist: do not mix MSVC .lib files with MinGW-built objects; prefer rebuilds or native import libs; and add the linker flag only as a temporary workaround. 's link-stage observations point precisely at this cross-toolchain incompatibility.

Member Avatar for Skeen

Project Uploaded:

(if anyone wants to play with it)

gl_texture.zip (605.2 KB)
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.