MinGW - Minimalist GNU for Windows

http://www.pcworld.com/businesscenter/article/256339/microsoft_delivers_a_blow_to_open_source_with_visual_studio_11.html#tk.rss_news
microsoft SDK's will no longer ships with complete build environment. microsoft vs express 11 only does metro apps.

 
-------------
Jim Michaels
jmichae3@...
JimM@...
http://JimsComputerRepairandWebDesign.com
http://JesusnJim.com (my personal site, has software)
---
Computer memory measurements, SSD measurements, microsoft disk size measurements (note: they will say GB or MB or KB or TB when it is not!):
[KiB] [MiB] [GiB] [TiB]
[2^10B=1,024B=1KiB]
[2^20B=1,048,576B=1MiB]
[2^30B=1,073,741,824B=1GiB]
[2^40B=1,099,511,627,776B=1TiB]
hard disk industry disk size measurements:
[KB] [MB] [GB] [TB]
[10^3B=1,000B=1KB]
[10^6B=1,000,000B=1MB]
[10^9B=1,000,000,000B=1GB]
[10^12B=1,000,000,000,000B=1TB]

Hi all, please help me on any resource of programming Microsoft Office using MingW ! Many thanks.

http://yosttech.com/templates/beez/yahmlc.php Zarko Vidic

Hello,


        I am building gnutls using mingw on windows

        make is giving error

        \gnutls-3.0.19\gl/scandir.c:97: undefined reference to
`_imp__opendir'
        \gnutls-3.0.19\gl/scandir.c:117: undefined reference to
`_imp__readdir'
        \gnutls-3.0.19\gl/scandir.c:183: undefined reference to
`_imp__closedir'


        this is the common error i faced in other packages.


        Help me to sort out this error.

On Thu, May 9, 2013 at 8:47 AM, Hardik Gohil wrote:
> Hello,
>
>
>         I am building gnutls using mingw on windows
>
>         make is giving error

You need to show the command line giving the errors and not just the errors.

>
>         \gnutls-3.0.19\gl/scandir.c:97: undefined reference to
> `_imp__opendir'
>         \gnutls-3.0.19\gl/scandir.c:117: undefined reference to
> `_imp__readdir'
>         \gnutls-3.0.19\gl/scandir.c:183: undefined reference to
> `_imp__closedir'
>
>
>         this is the common error i faced in other packages.
>
>
>         Help me to sort out this error.

The issue appears to be incorrect command line structure.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

On 5/9/2013 9:13 AM, Earnie Boyd wrote:
> On Thu, May 9, 2013 at 8:47 AM, Hardik Gohil wrote:
>> Hello,
>>
>>
>>          I am building gnutls using mingw on windows
>>
>>          make is giving error
>
> You need to show the command line giving the errors and not just the errors.
>
>>
>>          \gnutls-3.0.19\gl/scandir.c:97: undefined reference to
>> `_imp__opendir'
>>          \gnutls-3.0.19\gl/scandir.c:117: undefined reference to
>> `_imp__readdir'
>>          \gnutls-3.0.19\gl/scandir.c:183: undefined reference to
>> `_imp__closedir'
>>
>>
>>          this is the common error i faced in other packages.
>>
>>
>>          Help me to sort out this error.
>
> The issue appears to be incorrect command line structure.
>
short answer, one that I've stumbled across more than once myself the 
last few weeks: create EITHER static or dynamic libs - but not both.

> Date: Thu, 09 May 2013 14:13:07 -0400
> From: Gorshkov <gorshkovlists@...>
> 
> short answer, one that I've stumbled across more than once myself the 
> last few weeks: create EITHER static or dynamic libs - but not both.

Actually, quite a few packages can do both at the same time.  It's a
question of how recent the autotools they use.

And I don't think this is the problem here, because MinGW's dirent
functions are in libmingwex.a.  This command:

    nm -A libmingwex.a | grep "dir$"

produces:

  (standard input):1283:\usr\lib\libmingwex.a:dirent.o:00000390 T _closedir
  (standard input):1289:\usr\lib\libmingwex.a:dirent.o:00000000 T _opendir
  (standard input):1290:\usr\lib\libmingwex.a:dirent.o:00000240 T _readdir
  (standard input):1291:\usr\lib\libmingwex.a:dirent.o:000003f0 T _rewinddir
  (standard input):1292:\usr\lib\libmingwex.a:dirent.o:00000490 T _seekdir
  (standard input):1296:\usr\lib\libmingwex.a:dirent.o:00000450 T _telldir
  (standard input):1304:\usr\lib\libmingwex.a:wdirent.o:00000360 T __wclosedir
  (standard input):1308:\usr\lib\libmingwex.a:wdirent.o:00000000 T __wopendir
  (standard input):1309:\usr\lib\libmingwex.a:wdirent.o:00000250 T __wreaddir
  (standard input):1310:\usr\lib\libmingwex.a:wdirent.o:000003c0 T __wrewinddir
  (standard input):1311:\usr\lib\libmingwex.a:wdirent.o:00000460 T __wseekdir
  (standard input):1312:\usr\lib\libmingwex.a:wdirent.o:00000420 T __wtelldir

IOW, these functions are statically linked into MinGW programs, so it
is unusual to see _imp__opendir etc, which come from some import
library.

> Date: Thu, 09 May 2013 14:13:07 -0400
> From: Gorshkov <gorshkovlists@...>
> 
> short answer, one that I've stumbled across more than once myself the 
> last few weeks: create EITHER static or dynamic libs - but not both.

Actually, quite a few packages can do both at the same time.  It's a
question of how recent the autotools they use.

And I don't think this is the problem here, because MinGW's dirent
functions are in libmingwex.a.  This command:

    nm -A libmingwex.a | grep "dir$"

produces:

  (standard input):1283:\usr\lib\libmingwex.a:dirent.o:00000390 T _closedir
  (standard input):1289:\usr\lib\libmingwex.a:dirent.o:00000000 T _opendir
  (standard input):1290:\usr\lib\libmingwex.a:dirent.o:00000240 T _readdir
  (standard input):1291:\usr\lib\libmingwex.a:dirent.o:000003f0 T _rewinddir
  (standard input):1292:\usr\lib\libmingwex.a:dirent.o:00000490 T _seekdir
  (standard input):1296:\usr\lib\libmingwex.a:dirent.o:00000450 T _telldir
  (standard input):1304:\usr\lib\libmingwex.a:wdirent.o:00000360 T __wclosedir
  (standard input):1308:\usr\lib\libmingwex.a:wdirent.o:00000000 T __wopendir
  (standard input):1309:\usr\lib\libmingwex.a:wdirent.o:00000250 T __wreaddir
  (standard input):1310:\usr\lib\libmingwex.a:wdirent.o:000003c0 T __wrewinddir
  (standard input):1311:\usr\lib\libmingwex.a:wdirent.o:00000460 T __wseekdir
  (standard input):1312:\usr\lib\libmingwex.a:wdirent.o:00000420 T __wtelldir

IOW, these functions are statically linked into MinGW programs, so it
is unusual to see _imp__opendir etc, which come from some import
library.

Finally, I built this version of GnuTLS myself with MinGW, and didn't
see any such problems.

On 5/9/2013 3:39 PM, Eli Zaretskii wrote:
>> Date: Thu, 09 May 2013 14:13:07 -0400
>> From: Gorshkov <gorshkovlists@...>
>>
>> short answer, one that I've stumbled across more than once myself the
>> last few weeks: create EITHER static or dynamic libs - but not both.
>
> Actually, quite a few packages can do both at the same time.  It's a
> question of how recent the autotools they use.
>
> And I don't think this is the problem here, because MinGW's dirent
> functions are in libmingwex.a.  This command:
>
>      nm -A libmingwex.a | grep "dir$"
>
> produces:
>
>    (standard input):1283:\usr\lib\libmingwex.a:dirent.o:00000390 T _closedir
>    (standard input):1289:\usr\lib\libmingwex.a:dirent.o:00000000 T _opendir
>    (standard input):1290:\usr\lib\libmingwex.a:dirent.o:00000240 T _readdir
>    (standard input):1291:\usr\lib\libmingwex.a:dirent.o:000003f0 T _rewinddir
>    (standard input):1292:\usr\lib\libmingwex.a:dirent.o:00000490 T _seekdir
>    (standard input):1296:\usr\lib\libmingwex.a:dirent.o:00000450 T _telldir
>    (standard input):1304:\usr\lib\libmingwex.a:wdirent.o:00000360 T __wclosedir
>    (standard input):1308:\usr\lib\libmingwex.a:wdirent.o:00000000 T __wopendir
>    (standard input):1309:\usr\lib\libmingwex.a:wdirent.o:00000250 T __wreaddir
>    (standard input):1310:\usr\lib\libmingwex.a:wdirent.o:000003c0 T __wrewinddir
>    (standard input):1311:\usr\lib\libmingwex.a:wdirent.o:00000460 T __wseekdir
>    (standard input):1312:\usr\lib\libmingwex.a:wdirent.o:00000420 T __wtelldir
>
> IOW, these functions are statically linked into MinGW programs, so it
> is unusual to see _imp__opendir etc, which come from some import
> library.
>
> Finally, I built this version of GnuTLS myself with MinGW, and didn't
> see any such problems.
>

yes most *can* - I'm not disputing that. I guess I have to go into my 
long answer after all - I was hoping *not* to, because I've done some 
quick checking, but no in-depth investigation, and didn't want to give a 
long-winded answer that turned out to be coming from out of my arse :)


So, here it is ...

Many packages use different compiler settings when generating "static" 
vs "shared" object files - PIC vs non-PIC, etc. Some packages deal with 
this by renaming some of their routines via macros, depending on shared 
or non-shared .... but if their Makefile setup is such that they do NOT 
generate seperate obj files for each, what you wind up with is a case of 
the object file generated for the static library (containing code for 
XXX()) being used in the SHARED library (which has been redefined to 
expect imp_XXX()) - which is exactly the case here.

So, I think my short answer holds - if you're having that particular 
problem, configure and generate static OR shared - but not both.

@ Eli Zaretskii
what may be the problem, if buiding of either of static or dynamic is not a
problem.


On Fri, May 10, 2013 at 1:09 AM, Eli Zaretskii <eliz@...> wrote:

> > Date: Thu, 09 May 2013 14:13:07 -0400
> > From: Gorshkov <gorshkovlists@...>
> >
> > short answer, one that I've stumbled across more than once myself the
> > last few weeks: create EITHER static or dynamic libs - but not both.
>
> Actually, quite a few packages can do both at the same time.  It's a
> question of how recent the autotools they use.
>
> And I don't think this is the problem here, because MinGW's dirent
> functions are in libmingwex.a.  This command:
>
>     nm -A libmingwex.a | grep "dir$"
>
> produces:
>
>   (standard input):1283:\usr\lib\libmingwex.a:dirent.o:00000390 T _closedir
>   (standard input):1289:\usr\lib\libmingwex.a:dirent.o:00000000 T _opendir
>   (standard input):1290:\usr\lib\libmingwex.a:dirent.o:00000240 T _readdir
>   (standard input):1291:\usr\lib\libmingwex.a:dirent.o:000003f0 T
> _rewinddir
>   (standard input):1292:\usr\lib\libmingwex.a:dirent.o:00000490 T _seekdir
>   (standard input):1296:\usr\lib\libmingwex.a:dirent.o:00000450 T _telldir
>   (standard input):1304:\usr\lib\libmingwex.a:wdirent.o:00000360 T
> __wclosedir
>   (standard input):1308:\usr\lib\libmingwex.a:wdirent.o:00000000 T
> __wopendir
>   (standard input):1309:\usr\lib\libmingwex.a:wdirent.o:00000250 T
> __wreaddir
>   (standard input):1310:\usr\lib\libmingwex.a:wdirent.o:000003c0 T
> __wrewinddir
>   (standard input):1311:\usr\lib\libmingwex.a:wdirent.o:00000460 T
> __wseekdir
>   (standard input):1312:\usr\lib\libmingwex.a:wdirent.o:00000420 T
> __wtelldir
>
> IOW, these functions are statically linked into MinGW programs, so it
> is unusual to see _imp__opendir etc, which come from some import
> library.
>
> Finally, I built this version of GnuTLS myself with MinGW, and didn't
> see any such problems.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list
> etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:mingw-users-request@...
>

thanks for your replies

I have build lot of libraries,which library i have to build shared or
static so that i can solve this problem...






On Fri, May 10, 2013 at 3:32 AM, Gorshkov <gorshkovlists@...> wrote:

> On 5/9/2013 3:39 PM, Eli Zaretskii wrote:
> >> Date: Thu, 09 May 2013 14:13:07 -0400
> >> From: Gorshkov <gorshkovlists@...>
> >>
> >> short answer, one that I've stumbled across more than once myself the
> >> last few weeks: create EITHER static or dynamic libs - but not both.
> >
> > Actually, quite a few packages can do both at the same time.  It's a
> > question of how recent the autotools they use.
> >
> > And I don't think this is the problem here, because MinGW's dirent
> > functions are in libmingwex.a.  This command:
> >
> >      nm -A libmingwex.a | grep "dir$"
> >
> > produces:
> >
> >    (standard input):1283:\usr\lib\libmingwex.a:dirent.o:00000390 T
> _closedir
> >    (standard input):1289:\usr\lib\libmingwex.a:dirent.o:00000000 T
> _opendir
> >    (standard input):1290:\usr\lib\libmingwex.a:dirent.o:00000240 T
> _readdir
> >    (standard input):1291:\usr\lib\libmingwex.a:dirent.o:000003f0 T
> _rewinddir
> >    (standard input):1292:\usr\lib\libmingwex.a:dirent.o:00000490 T
> _seekdir
> >    (standard input):1296:\usr\lib\libmingwex.a:dirent.o:00000450 T
> _telldir
> >    (standard input):1304:\usr\lib\libmingwex.a:wdirent.o:00000360 T
> __wclosedir
> >    (standard input):1308:\usr\lib\libmingwex.a:wdirent.o:00000000 T
> __wopendir
> >    (standard input):1309:\usr\lib\libmingwex.a:wdirent.o:00000250 T
> __wreaddir
> >    (standard input):1310:\usr\lib\libmingwex.a:wdirent.o:000003c0 T
> __wrewinddir
> >    (standard input):1311:\usr\lib\libmingwex.a:wdirent.o:00000460 T
> __wseekdir
> >    (standard input):1312:\usr\lib\libmingwex.a:wdirent.o:00000420 T
> __wtelldir
> >
> > IOW, these functions are statically linked into MinGW programs, so it
> > is unusual to see _imp__opendir etc, which come from some import
> > library.
> >
> > Finally, I built this version of GnuTLS myself with MinGW, and didn't
> > see any such problems.
> >
>
> yes most *can* - I'm not disputing that. I guess I have to go into my
> long answer after all - I was hoping *not* to, because I've done some
> quick checking, but no in-depth investigation, and didn't want to give a
> long-winded answer that turned out to be coming from out of my arse :)
>
>
> So, here it is ...
>
> Many packages use different compiler settings when generating "static"
> vs "shared" object files - PIC vs non-PIC, etc. Some packages deal with
> this by renaming some of their routines via macros, depending on shared
> or non-shared .... but if their Makefile setup is such that they do NOT
> generate seperate obj files for each, what you wind up with is a case of
> the object file generated for the static library (containing code for
> XXX()) being used in the SHARED library (which has been redefined to
> expect imp_XXX()) - which is exactly the case here.
>
> So, I think my short answer holds - if you're having that particular
> problem, configure and generate static OR shared - but not both.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list
> etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:mingw-users-request@...
>

> Date: Thu, 09 May 2013 18:02:38 -0400
> From: Gorshkov <gorshkovlists@...>
> 
> So, I think my short answer holds - if you're having that particular 
> problem, configure and generate static OR shared - but not both.

I agree, but the symptoms of the problem that requires such
differentiation are usually different from what was reported here, at
least in my experience.

> Date: Fri, 10 May 2013 10:20:06 +0530
> From: Hardik Gohil <hardikgohil1988@...>
> 
> I have attached the build output for #make V=1 in build.log file

That's not V=1, and I don't see any error messages in the log.

> I have configured with ./configure --prefix=/opt/emo2/  --enable-shared
> --disable-static

/opt/emo2 is not a Windows file name, it lacks a drive letter.  (I'm
not saying that this is the reason for the problem, but still.)

> Date: Fri, 10 May 2013 10:50:46 +0530
> From: Hardik Gohil <hardikgohil1988@...>
> 
> what may be the problem, if buiding of either of static or dynamic is not a
> problem.

Hard to tell without seeing at least the link command line that caused
this error.

I think mistake gone in tee command,this is the error message

../gl/.libs/libgnu.a(scandir.o): In function `scandir':
C:\MinGW\msys\1.0\home\system\webkit\build_sources\gnutls-3.0.10\gl/scandir.c:98:
undefined reference to `_imp__opendir'
C:\MinGW\msys\1.0\home\system\webkit\build_sources\gnutls-3.0.10\gl/scandir.c:118:
undefined reference to `_imp__readdir'
C:\MinGW\msys\1.0\home\system\webkit\build_sources\gnutls-3.0.10\gl/scandir.c:184:
undefined reference to `_imp__closedir
collect2.exe: error: ld returned 1 exit status
make[3]: *** [libgnutls.la] Error 1
make[3]: Leaving directory
`/home/system/webkit/build_sources/gnutls-3.0.10/lib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/system/webkit/build_sources/gnutls-3.0.10/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/system/webkit/build_sources/gnutls-3.0.10'
make: *** [all] Error 2


On Fri, May 10, 2013 at 12:20 PM, Eli Zaretskii <eliz@...> wrote:

> > Date: Fri, 10 May 2013 10:20:06 +0530
> > From: Hardik Gohil <hardikgohil1988@...>
> >
> > I have attached the build output for #make V=1 in build.log file
>
> That's not V=1, and I don't see any error messages in the log.
>
> > I have configured with ./configure --prefix=/opt/emo2/  --enable-shared
> > --disable-static
>
> /opt/emo2 is not a Windows file name, it lacks a drive letter.  (I'm
> not saying that this is the reason for the problem, but still.)
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list
> etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:mingw-users-request@...
>

> Date: Fri, 10 May 2013 12:37:14 +0530
> From: Hardik Gohil <hardikgohil1988@...>
> 
> I think mistake gone in tee command,this is the error message
> 
> ../gl/.libs/libgnu.a(scandir.o): In function `scandir':
> C:\MinGW\msys\1.0\home\system\webkit\build_sources\gnutls-3.0.10\gl/scandir.c:98:
> undefined reference to `_imp__opendir'
> C:\MinGW\msys\1.0\home\system\webkit\build_sources\gnutls-3.0.10\gl/scandir.c:118:
> undefined reference to `_imp__readdir'
> C:\MinGW\msys\1.0\home\system\webkit\build_sources\gnutls-3.0.10\gl/scandir.c:184:
> undefined reference to `_imp__closedir
> collect2.exe: error: ld returned 1 exit status
> make[3]: *** [libgnutls.la] Error 1
> make[3]: Leaving directory
> `/home/system/webkit/build_sources/gnutls-3.0.10/lib'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory
> `/home/system/webkit/build_sources/gnutls-3.0.10/lib'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/system/webkit/build_sources/gnutls-3.0.10'
> make: *** [all] Error 2

Once again, please show the full link command line that causes these
error messages.  You cannot expect us to help you without showing at
least that, because we need to see the libraries against which GCC is
trying to link.  So please type "make V=1" and post here the GCC command
line that immediately precedes these errors.

Full link command error messages with gcc command that precedes errors...




make[3]: Leaving directory
`/home/system/webkit/build_sources/gnutls-3.0.6/lib/nettle'
make[3]: Entering directory
`/home/system/webkit/build_sources/gnutls-3.0.6/lib'
/bin/sh ../libtool  --tag=CC   --mode=link gcc -std=gnu99    -g -O2
-no-undefined -version-info 30:2:2 -Wl,--version-script=./libgnutls.map
-L/opt/emo2/lib -lnettle -L/opt/emo2/lib -lhogweed -L/opt/emo2/lib -lgmp
-R/op
t/emo2/lib  -Wl,--output-def,libgnutls-28.def -L/opt/emo2/lib -o
libgnutls.la -rpath /opt/emo2/lib  gnutls_record.lo gnutls_compress.lo
debug.lo gnutls_cipher.lo gnutls_mbuffers.lo gnutls_buffers.lo
gnutls_handshake.lo g
nutls_num.lo gnutls_errors.lo gnutls_dh.lo gnutls_kx.lo gnutls_priority.lo
gnutls_hash_int.lo gnutls_cipher_int.lo gnutls_session.lo gnutls_db.lo
x509_b64.lo gnutls_extensions.lo gnutls_auth.lo gnutls_v2_compat.lo gnutls
_datum.lo gnutls_session_pack.lo gnutls_mpi.lo gnutls_pk.lo gnutls_cert.lo
gnutls_global.lo gnutls_constate.lo gnutls_anon_cred.lo pkix_asn1_tab.lo
gnutls_asn1_tab.lo gnutls_mem.lo gnutls_ui.lo gnutls_sig.lo gnutls_ecc.l
o gnutls_dh_primes.lo gnutls_alert.lo system.lo gnutls_str.lo
gnutls_state.lo gnutls_x509.lo gnutls_rsa_export.lo gnutls_helper.lo
gnutls_supplemental.lo random.lo crypto-api.lo gnutls_privkey.lo
gnutls_pcert.lo gnutls_p
ubkey.lo locks.lo hash.lo gnutls_dtls.lo system_override.lo
crypto-backend.lo  gnutls_srp.lo gnutls_psk.lo ../gl/libgnu.la x509/
libgnutls_x509.la accelerated/libaccelerated.la ext/libgnutls_ext.la auth/
libgnutls_auth.la
algorithms/libgnutls_alg.la -lz -lintl -lws2_32  -lpthread openpgp/
libgnutls_openpgp.la opencdk/libminiopencdk.la minitasn1/libminitasn1.lanettle/
libcrypto.la
libtool: link: rm -fr  .libs/libgnutls.dll.a
libtool: link: gcc -std=gnu99 -shared  .libs/gnutls_record.o
.libs/gnutls_compress.o .libs/debug.o .libs/gnutls_cipher.o
.libs/gnutls_mbuffers.o .libs/gnutls_buffers.o .libs/gnutls_handshake.o
.libs/gnutls_num.o .libs/gn
utls_errors.o .libs/gnutls_dh.o .libs/gnutls_kx.o .libs/gnutls_priority.o
.libs/gnutls_hash_int.o .libs/gnutls_cipher_int.o .libs/gnutls_session.o
.libs/gnutls_db.o .libs/x509_b64.o .libs/gnutls_extensions.o .libs/gnutls
_auth.o .libs/gnutls_v2_compat.o .libs/gnutls_datum.o
.libs/gnutls_session_pack.o .libs/gnutls_mpi.o .libs/gnutls_pk.o
.libs/gnutls_cert.o .libs/gnutls_global.o .libs/gnutls_constate.o
.libs/gnutls_anon_cred.o .libs/pkix
_asn1_tab.o .libs/gnutls_asn1_tab.o .libs/gnutls_mem.o .libs/gnutls_ui.o
.libs/gnutls_sig.o .libs/gnutls_ecc.o .libs/gnutls_dh_primes.o
.libs/gnutls_alert.o .libs/system.o .libs/gnutls_str.o .libs/gnutls_state.o
.libs/gn
utls_x509.o .libs/gnutls_rsa_export.o .libs/gnutls_helper.o
.libs/gnutls_supplemental.o .libs/random.o .libs/crypto-api.o
.libs/gnutls_privkey.o .libs/gnutls_pcert.o .libs/gnutls_pubkey.o
.libs/locks.o .libs/hash.o .libs
/gnutls_dtls.o .libs/system_override.o .libs/crypto-backend.o
.libs/gnutls_srp.o .libs/gnutls_psk.o  -Wl,--whole-archive
../gl/.libs/libgnu.a x509/.libs/libgnutls_x509.a
accelerated/.libs/libaccelerated.a ext/.libs/libgn
utls_ext.a auth/.libs/libgnutls_auth.a algorithms/.libs/libgnutls_alg.a
openpgp/.libs/libgnutls_openpgp.a opencdk/.libs/libminiopencdk.a
minitasn1/.libs/libminitasn1.a nettle/.libs/libcrypto.a
-Wl,--no-whole-archive  -L/
opt/emo2/lib -lnettle -lhogweed /opt/emo2/lib/libgmp.dll.a
/mingw/lib/libiconv.dll.a -lz /mingw/lib/libintl.dll.a -L/mingw/lib
-lws2_32 -lpthread  -O2 -Wl,--version-script=./libgnutls.map
-Wl,--output-def -Wl,libgnutls-2
8.def   -o .libs/libgnutls-28.dll -Wl,--enable-auto-image-base -Xlinker
--out-implib -Xlinker .libs/libgnutls.dll.a
../gl/.libs/libgnu.a(scandir.o): In function `scandir':
C:\MinGW\msys\1.0\home\system\webkit\build_sources\gnutls-3.0.6\gl/scandir.c:98:
undefined reference to `_imp__opendir'
C:\MinGW\msys\1.0\home\system\webkit\build_sources\gnutls-3.0.6\gl/scandir.c:118:
undefined reference to `_imp__readdir'
C:\MinGW\msys\1.0\home\system\webkit\build_sources\gnutls-3.0.6\gl/scandir.c:184:
undefined reference to `_imp__closedir'
collect2.exe: error: ld returned 1 exit status
make[3]: *** [libgnutls.la] Error 1
make[3]: Leaving directory
`/home/system/webkit/build_sources/gnutls-3.0.6/lib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/system/webkit/build_sources/gnutls-3.0.6/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/system/webkit/build_sources/gnutls-3.0.6'
make: *** [all] Error 2


On Fri, May 10, 2013 at 1:33 PM, Eli Zaretskii <eliz@...> wrote:

> > Date: Fri, 10 May 2013 12:37:14 +0530
> > From: Hardik Gohil <hardikgohil1988@...>
> >
> > I think mistake gone in tee command,this is the error message
> >
> > ../gl/.libs/libgnu.a(scandir.o): In function `scandir':
> >
> C:\MinGW\msys\1.0\home\system\webkit\build_sources\gnutls-3.0.10\gl/scandir.c:98:
> > undefined reference to `_imp__opendir'
> >
> C:\MinGW\msys\1.0\home\system\webkit\build_sources\gnutls-3.0.10\gl/scandir.c:118:
> > undefined reference to `_imp__readdir'
> >
> C:\MinGW\msys\1.0\home\system\webkit\build_sources\gnutls-3.0.10\gl/scandir.c:184:
> > undefined reference to `_imp__closedir
> > collect2.exe: error: ld returned 1 exit status
> > make[3]: *** [libgnutls.la] Error 1
> > make[3]: Leaving directory
> > `/home/system/webkit/build_sources/gnutls-3.0.10/lib'
> > make[2]: *** [all-recursive] Error 1
> > make[2]: Leaving directory
> > `/home/system/webkit/build_sources/gnutls-3.0.10/lib'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory
> `/home/system/webkit/build_sources/gnutls-3.0.10'
> > make: *** [all] Error 2
>
> Once again, please show the full link command line that causes these
> error messages.  You cannot expect us to help you without showing at
> least that, because we need to see the libraries against which GCC is
> trying to link.  So please type "make V=1" and post here the GCC command
> line that immediately precedes these errors.
>

> Date: Fri, 10 May 2013 13:48:46 +0530
> From: Hardik Gohil <hardikgohil1988@...>
> Cc: MinGW Users List <mingw-users@...>
> 
> Full link command error messages with gcc command that precedes errors...

Thanks.  This mentions several .dll.a import libraries, none of which
should include _imp__readdir etc.  I suggest to scan them all and find
the one which does.  Like this:

  nm -A libgnutls.dll.a | fgrep _imp__readdir

and the same with other .dll.a libraries.  If you don't find any hits,
do the same with all your .dll.a libraries in the MinGW lib/
directory.

Also, what version of the MinGW runtime are you using to build this?

On Fri, May 10, 2013 at 12:50 AM, Hardik Gohil wrote:

Hardik, please read the Etiquette section of http://mingw.org/lists.shtml.

> I have attached the build output for #make V=1 in build.log file
>
> I have configured with ./configure --prefix=/opt/emo2/  --enable-shared
> --disable-static

Does it help if you use --prefix=/mingw instead?  I'm thinking libtool
is confused by the prefix.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

On Fri, May 10, 2013 at 7:11 PM, Earnie Boyd

>Does it help if you use --prefix=/mingw instead?  I'm thinking libtool
>is confused by the prefix.


No it didn't work.

> Date: Fri, 10 May 2013 19:00:13 +0530
> From: Hardik Gohil <hardikgohil1988@...>
> 
> None of this .dll.a libraries and libraries of /mingw/lib has definition of
> _imp__opendir
> 
> grep result for opendir
> 
> C:/MinGW/lib/libmingwex.a:dirent.o:00000000     T _opendir
> C:/MinGW/lib/libmingwex.a:wdirent.o:00000000   T __wopendir
> C:/MinGW/lib/libltdl.a:libltdl_libltdl_la-ltdl.o:         U _opendir

Then I'd do the same with all the *.o files in all the sub-directories
of the gnutls tree.

> How can i check Version of MinGW runtime,any command ?

Look in the _mingw.h header file in the include directory.

I found the definition of _imp__opendir in libevil.dll.a which i installed
in non-default directory

I dont know why it was unable to link automatically..

I have to explicitly link to that library,by adding library path to LDFLAGS
in Makefile.

Thank you guys for help......!!!

At last error is Solved....!!!

On Sun, May 12, 2013 at 2:20 AM, Hardik Gohil wrote:
> I found the definition of _imp__opendir in libevil.dll.a which i installed
> in non-default directory
>

The non-default directory is never searched for by GCC you have to do ...

> I dont know why it was unable to link automatically..
>
> I have to explicitly link to that library,by adding library path to LDFLAGS
> in Makefile.
>

... what you did here.  Your issue points to the reason we encourage
to use a prefix of /mingw when installing libraries.


-- 
Earnie
-- https://sites.google.com/site/earnieboyd