Salut!
 
Voilà, j'ai un probleme de link avec dev c++ (sous windows) (qui utilise mingw32), la compilation est bonne, l'ensemble compil et link sous linux par contre.
 
voilà le type de ligne:
 
tif_win32.c C:\Dev-Cpp\lib\libtiff.lib(tif_win32.obj)(.text+0x48f)
variable '_iob' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
 
j'essaye uniquement de rajouter libtiff.lib et lorsque je link,  
j'ai ce message d'erreur, j'ai regardé la doc de ld, ss succès, ou j'ai loupé qqchose, en fouillant un peu, j'ai essayé, en toute logique de faire un --disable-auto-import sur cette lib, mais aucun changement. Quelqu'un à une idée ou un lien avec des infos, merci.

personne a une p'tite idée?

Peut etre une reponse ici :
http://groups.google.com/groups?q= [...] gle+Search
 
vw

Tu utilises mysql.h?

non, non, j'ai vu que certaine personnes avaient ce pb en relation avec mysql mais ds mon cas c'est un moteur 3D cross-platform sans base de données...

Ca ne vient pas, apparement, de mysql mais du linker et de l'importation de librairies externe .lib (pour moi par exemple c'est la librairie tiff)

En fait, un p'tit tour vers les pages man de ld :
 
--enable-auto-import
    Do  sophisticated linking of "_symbol" to "__imp__sym-
    bol" for DATA imports from DLLs, and create the neces-
    sary  thunking  symbols  when  building  the DLLs with
    those DATA exports. This generally will  'just  work'
    -- but sometimes you may see this message:
 
    "variable  '<var>' can't be auto-imported. Please read
    the documentation for ld's "--enable-auto-import"  for
    details."
 
    This message occurs when some (sub)expression accesses
    an address ultimately given by the  sum  of two  con-
    stants   (Win32   import   tables   only  allow  one).
    Instances where this may  occur  include  accesses  to
    member fields of struct variables imported from a DLL,
    as well as using a constant index into an array  vari-
    able  imported  from  a  DLL.   Any multiword variable
    (arrays, structs, long long,  etc)  may  trigger  this
    error  condition.   However,  regardless  of the exact
    data type of the offending exported variable, ld  will
    always detect it, issue the warning, and exit.
 
    There  are  several ways  to address this difficulty,
    regardless of the data type of the exported variable:
 
    One solution is to force one of the 'constants' to  be
    a  variable -- that is, unknown and un-optimizable at
    compile time.  For arrays, there  are  two  possibili-
    ties:  a)  make  the  indexee  (the array's address) a
    variable, or b) make the 'constant' index a variable.
    Thus:
 
     extern type extern_array[];
     extern_array[1] -->
        { volatile type *t=extern_array; t[1] }
 
    or
 
     extern type extern_array[];
     extern_array[1] -->
        { volatile int t=1; extern_array[t] }
 
    For structs (and most other multiword data types) the
    only option is to make the struct itself (or the  long
    long, or the ...) variable:
 
     extern struct s extern_struct;
     extern_struct.field -->
        { volatile struct s *t=&extern_struct; t->field }
 
    or
 
     extern long long extern_ll;
     extern_ll -->
       { volatile long long * local_ll=&extern_ll; *local_ll }
 
    A  second method of dealing with this difficulty is to
    abandon 'auto-import' for  the  offending  symbol  and
    mark  it  with  "__declspec(dllimport)".   However, in
    practice that requires using compile-time #defines  to
    indicate  whether  you  are building  a DLL, building
    client code that will  link to  the  DLL,  or  merely
    building/linking  to a static library.   In making the
    choice between the various methods  of  resolving  the
    'direct  address  with  constant  offset' problem, you
    should consider typical real-world usage:
 
    Original:
 
     --foo.h
     extern int arr[];
     --foo.c
     #include "foo.h"
     void main(int argc, char **argv){
       printf("%d\n",arr[1]);
     }
 
    Solution 1:
 
     --foo.h
     extern int arr[];
     --foo.c
     #include "foo.h"
     void main(int argc, char **argv){
       /* This workaround is for win32 and cygwin; do not "optimize" */
       volatile int *parr = arr;
       printf("%d\n",parr[1]);
     }
 
    Solution 2:
 
     --foo.h
     /* Note: auto-export is assumed (no __declspec(dllexport)) */
     #if (defined(_WIN32) || defined(__CYGWIN__)) && \
       !(defined(FOO_BUILD_DLL) || defined(FOO_STATIC))
     #define FOO_IMPORT __declspec(dllimport)
     #else
     #define FOO_IMPORT
     #endif
     extern FOO_IMPORT int arr[];
     --foo.c
     #include "foo.h"
     void main(int argc, char **argv){
       printf("%d\n",arr[1]);
     }
 
    A third way to avoid this problem is to  re-code  your
    library  to use  a functional interface rather than a
    data  interface  for  the  offending  variables  (e.g.
    set_foo() and get_foo() accessor functions).
 
...Les solutions ne sont pas forcément super simple a mettre en oeuvre.

Bon, apparement en recompilant les sources des libs (j'ai essayé avec la libjpeg et une lib png fait maison qui ne passaient pas également) avec dev, il n'y a plus de pbs....