From: Jim M. <jmi...@ya...> - 2012-01-28 08:07:02
|
I had to do this in mingw whereas I did not have to do this in mingw-w64. #if defined(__MINGW32__) #define __MSVCRT_VERSION__ 0x800 #define _WIN32_WINNT 0x0500 #endif ... if (_fseeki64(fsrc, pos, SEEK_SET)) { printf("ERROR: could not set file pointer.(1)\n"); fclose(fsrc); free(diskBuffer); return 1; } but now I get this link error extrchnk.o:extrchnk.cpp:(.text+0xeb8): undefined reference to `_fseeki64' collect2: ld returned 1 exit status gcc version 4.6.1 (GCC) compiler switches: c:\mingw\bin\g++.exe -Wall -Wextra -v -save-temps -Xlinker -Map=extrchnk.map -O -s -isystem /libpq/ -isystem /libpq/server/libpq/ -isystem /prj/fltk/fltk-2.0.x-alpha-r9042/ -isystem /prj/fltk/fltk-2.0.x-alpha-r9042/lib/ -isystem /prj/zlib-1.2.5/ -isystem /prj/boost/boost32 -o 32\extrchnk.exe extrchnk.cpp atoi64.cpp -lstdc++ 32\extrchnk.manifest.res "-lkernel32" 2>32\errgw32extrchnk COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-v' '-save-temps' '-O' '-s' '-isystem' '/libpq/' '-isystem' '/libpq/server/libpq/' '-isystem' '/prj/fltk/fltk-2.0.x-alpha-r9042/' '-isystem' '/prj/fltk/fltk-2.0.x-alpha-r9042/lib/' '-isystem' '/prj/zlib-1.2.5/' '-isystem' '/prj/boost/boost32' '-o' '32\extrchnk.exe' '-shared-libgcc' '-mtune=i386' '-march=i386' c:/mingw/bin/../libexec/gcc/mingw32/4.6.1/cc1plus.exe -E -quiet -v -iprefix c:\mingw\bin\../lib/gcc/mingw32/4.6.1/ -isystem /libpq/ -isystem /libpq/server/libpq/ -isystem /prj/fltk/fltk-2.0.x-alpha-r9042/ -isystem /prj/fltk/fltk-2.0.x-alpha-r9042/lib/ -isystem /prj/zlib-1.2.5/ -isystem /prj/boost/boost32 extrchnk.cpp -mtune=i386 -march=i386 -Wall -Wextra -O -fpch-preprocess -o extrchnk.ii I wonder if someone can explain why in the COLLECT_GCC_OPTIONS -o is a .ii file and -o is also specified elsewhere when I turn on -save-temps and -v... ------------- Jim Michaels jmi...@ya... JimM@JimsComputerRepairandWebDesign.com 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] |
From: Eli Z. <el...@gn...> - 2012-01-28 09:15:01
|
> Date: Sat, 28 Jan 2012 00:06:55 -0800 (PST) > From: Jim Michaels <jmi...@ya...> > > I had to do this in mingw whereas I did not have to do this in mingw-w64. > #if defined(__MINGW32__) > #define __MSVCRT_VERSION__ 0x800 > #define _WIN32_WINNT 0x0500 > #endif > ... > if (_fseeki64(fsrc, pos, SEEK_SET)) { > printf("ERROR: could not set file pointer.(1)\n"); > fclose(fsrc); > free(diskBuffer); > return 1; > } > > > > > but now I get this link error > > extrchnk.o:extrchnk.cpp:(.text+0xeb8): undefined reference to `_fseeki64' > collect2: ld returned 1 exit status Since this function exists in version 8.0 or later of MSVCRT, you probably need to link with -lmsvcr80 in the link command line. Note that this probably means the program will not work on machines that don't have msvcr80.dll installed. |
From: Jim M. <jmi...@ya...> - 2012-01-28 10:19:50
|
not on my XP system. no msvcrt80.dll here. what's on here is msvcrt.dll 7.0.2600.5512 so I guess I can't - ahh, I know, I will use a backrev version of mingw-w64 auto 20111127, that works great. Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. Fri 01/27/2012 22:43:19.93|C:\cd|>cd \windows\system32 Sat 01/28/2012 1:32:53.10|C:\WINDOWS\system32|>dir msvcrt* Volume in drive C is wd 2000 Volume Serial Number is 783C-0FA9 Directory of C:\WINDOWS\system32 04/14/2008 04:42 AM 343,040 msvcrt.dll 07/16/2003 08:31 AM 253,952 msvcrt20.dll 04/13/2008 11:00 PM 61,440 msvcrt40.dll 3 File(s) 658,432 bytes 0 Dir(s) 1,176,671,272,960 bytes free Sat 01/28/2012 1:33:02.56|C:\WINDOWS\system32|>\u\which msvcrt80.dll msvcrt80.dll not found in ( C:\Program Files\PHP\ C:\gnuwin32\GetGnuWin32\bin C:\gnuwin32\GetGnuWin32\gnuwin32\sbin C:\gnuwin32\GetGnuWin32\gnuwin32\bin C:\Perl\site\bin C:\Perl\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\system32\WBEM C:\Program Files\PHP c:\u c:\x c:\program files\7-zip c:\bin C:\Program Files\Csound\bin C:\Program Files\Common Files\Roxio Shared\9.0\DLLShared\ C:\Program Files\CMake 2.8\bin C:\Program Files\Common Files\HP\Digital Imaging\bin C:\Program Files\HP\Digital Imaging\bin\ C:\Program Files\HP\Digital Imaging\bin\Qt\Qt 4.3.3 C:\Program Files\WinMerge C:\Program Files\Java\jdk1.6.0_26\bin C:\Program Files\Common Files\Ulead Systems\MPEG c:\Program Files\Microsoft SQL Server\100\Tools\Binn\ c:\Program Files\Microsoft SQL Server\100\DTS\Binn\ C:\Program Files\Common Files\Intuit\QBPOSSDKRuntime C:\Program Files\QuickTime\QTSystem\ C:\Program Files\Microsoft Visual Studio 10.0\VC\bin C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\1033 C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\VDT C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\VDT\1033 C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\ProjectComponents C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\1033 C:\Program Files\Microsoft Visual Studio 10.0\Common7\Packages C:\Program Files\Microsoft Visual Studio 10.0\Common7\Packages\1033 C:\Program Files\OpenAxiom\bin C:\Program Files\Notepad++\ c:\tsepro ) Sat 01/28/2012 1:33:53.21|C:\WINDOWS\system32|>\u\which msvcrt90.dll msvcrt90.dll not found in ( C:\Program Files\PHP\ C:\gnuwin32\GetGnuWin32\bin C:\gnuwin32\GetGnuWin32\gnuwin32\sbin C:\gnuwin32\GetGnuWin32\gnuwin32\bin C:\Perl\site\bin C:\Perl\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\system32\WBEM C:\Program Files\PHP c:\u c:\x c:\program files\7-zip c:\bin C:\Program Files\Csound\bin C:\Program Files\Common Files\Roxio Shared\9.0\DLLShared\ C:\Program Files\CMake 2.8\bin C:\Program Files\Common Files\HP\Digital Imaging\bin C:\Program Files\HP\Digital Imaging\bin\ C:\Program Files\HP\Digital Imaging\bin\Qt\Qt 4.3.3 C:\Program Files\WinMerge C:\Program Files\Java\jdk1.6.0_26\bin C:\Program Files\Common Files\Ulead Systems\MPEG c:\Program Files\Microsoft SQL Server\100\Tools\Binn\ c:\Program Files\Microsoft SQL Server\100\DTS\Binn\ C:\Program Files\Common Files\Intuit\QBPOSSDKRuntime C:\Program Files\QuickTime\QTSystem\ C:\Program Files\Microsoft Visual Studio 10.0\VC\bin C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\1033 C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\VDT C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\VDT\1033 C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\ProjectComponents C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\1033 C:\Program Files\Microsoft Visual Studio 10.0\Common7\Packages C:\Program Files\Microsoft Visual Studio 10.0\Common7\Packages\1033 C:\Program Files\OpenAxiom\bin C:\Program Files\Notepad++\ c:\tsepro ) Sat 01/28/2012 1:34:00.09|C:\WINDOWS\system32|> >________________________________ > From: Eli Zaretskii <el...@gn...> >To: Jim Michaels <jmi...@ya...>; MinGW Users List <min...@li...> >Sent: Saturday, January 28, 2012 1:12 AM >Subject: Re: [Mingw-users] pain to use _fseeki64(), giving link errors > >> Date: Sat, 28 Jan 2012 00:06:55 -0800 (PST) >> From: Jim Michaels <jmi...@ya...> >> >> I had to do this in mingw whereas I did not have to do this in mingw-w64. >> #if defined(__MINGW32__) >> #define __MSVCRT_VERSION__ 0x800 >> #define _WIN32_WINNT 0x0500 >> #endif >> ... >> if (_fseeki64(fsrc, pos, SEEK_SET)) { >> printf("ERROR: could not set file pointer.(1)\n"); >> fclose(fsrc); >> free(diskBuffer); >> return 1; >> } >> >> >> >> >> but now I get this link error >> >> extrchnk.o:extrchnk.cpp:(.text+0xeb8): undefined reference to `_fseeki64' >> collect2: ld returned 1 exit status > >Since this function exists in version 8.0 or later of MSVCRT, you >probably need to link with -lmsvcr80 in the link command line. > >Note that this probably means the program will not work on machines >that don't have msvcr80.dll installed. > > > |
From: Eli Z. <el...@gn...> - 2012-01-28 11:03:43
|
> Date: Sat, 28 Jan 2012 02:19:43 -0800 (PST) > From: Jim Michaels <jmi...@ya...> > > not on my XP system. no msvcrt80.dll here. what's on here is msvcrt.dll 7.0.2600.5512 First, I said msvcr80.dll, not msvcrt80.dll. And second, "which" is not the appropriate tool here, because some directories where Windows looks for DLLs are not on PATH. Try GNU `find' (or `locate', if you have your locatedb up to date). Alternatively, link a program with "-lmsvcr80", and then try running it. Failing all that, you should be able to download the library from the MS site as a redistributable package. |
From: Gisle V. <gv...@br...> - 2012-01-28 14:32:11
|
"Jim Michaels" <jmi...@ya...> wrote: > Sat 01/28/2012 1:33:02.56|C:\WINDOWS\system32|>\u\which msvcrt80.dll > msvcrt80.dll not found in ( > C:\Program Files\PHP\ A tool that checks along the %PATH and report what's not there is not so useful IMHO. Please try my 'envtool' program that reports where things are and where things shouldn't be. E.g. the output here: G:\MingW32\src\inet\dsniff-2.4b2> envtool --path msvcr9*.dll Tue Jul 29 07:05:08 2008 : f:\windows\system32\msvcr90.dll Tue Jul 29 07:05:08 2008 : f:\windows\system32\msvcr90d.dll Wed Nov 07 06:19:34 2007 : g:\MingW32\bin\CMake2.8\bin\msvcr90.dll You see, during installation of some packages, they add their '.\bin' first in the PATH. Thus potentially shadowing old DLLs for up-to-date system-dlls (and adding to the DLL-hell). That was the case with CMake above before I moved it's '.\bin' further up the PATH. envtool (exe+source) is here: http://home.broadpark.no/~gvanem/misc/#envtool It also checks %INCLUDE for headers and %LIB for lib-files. Todo: look in registry under "App Path", make it more gcc centric (check %C_INCLUDE_PATH, %LIBRARY_PATH). More? --gv |
From: Earnie B. <ea...@us...> - 2012-01-28 14:48:16
|
On Sat, Jan 28, 2012 at 9:31 AM, Gisle Vanem <gv...@br...> wrote: > "Jim Michaels" <jmi...@ya...> wrote: > >> Sat 01/28/2012 1:33:02.56|C:\WINDOWS\system32|>\u\which msvcrt80.dll >> msvcrt80.dll not found in ( >> C:\Program Files\PHP\ > > A tool that checks along the %PATH and report what's not there is not > so useful IMHO. Please try my 'envtool' program that reports where things > are and where things shouldn't be. E.g. the output here: > > G:\MingW32\src\inet\dsniff-2.4b2> envtool --path msvcr9*.dll > > Tue Jul 29 07:05:08 2008 : f:\windows\system32\msvcr90.dll > Tue Jul 29 07:05:08 2008 : f:\windows\system32\msvcr90d.dll > Wed Nov 07 06:19:34 2007 : g:\MingW32\bin\CMake2.8\bin\msvcr90.dll > > You see, during installation of some packages, they add their '.\bin' > first in the PATH. Thus potentially shadowing old DLLs for up-to-date > system-dlls (and adding to the DLL-hell). That was the case with CMake > above before I moved it's '.\bin' further up the PATH. > This is the prescribed method if your application is dependent on the version of DLL. A new version of the DLL may break your application. So using a newer version of a DLL for an application that ships with an older version isn't a good thing. However, since the DLL actually resides in the directory with the application it should be used regardless of PATH as long as you don't delete the DLL. The DLL-hell is the reason for the implementation of manifest files. You can also create a directory foo.exe.local and store your DLL in that directory that foo.exe depends on. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Jim M. <jmi...@ya...> - 2012-02-01 07:53:09
|
just out of curiosity, how do I extract the dll version information without using windows explorer? >________________________________ > From: Earnie Boyd <ea...@us...> >To: MinGW Users List <min...@li...> >Sent: Saturday, January 28, 2012 6:48 AM >Subject: Re: [Mingw-users] pain to use _fseeki64(), giving link errors > >On Sat, Jan 28, 2012 at 9:31 AM, Gisle Vanem <gv...@br...> wrote: >> "Jim Michaels" <jmi...@ya...> wrote: >> >>> Sat 01/28/2012 1:33:02.56|C:\WINDOWS\system32|>\u\which msvcrt80.dll >>> msvcrt80.dll not found in ( >>> C:\Program Files\PHP\ >> >> A tool that checks along the %PATH and report what's not there is not >> so useful IMHO. Please try my 'envtool' program that reports where things >> are and where things shouldn't be. E.g. the output here: >> >> G:\MingW32\src\inet\dsniff-2.4b2> envtool --path msvcr9*.dll >> >> Tue Jul 29 07:05:08 2008 : f:\windows\system32\msvcr90.dll >> Tue Jul 29 07:05:08 2008 : f:\windows\system32\msvcr90d.dll >> Wed Nov 07 06:19:34 2007 : g:\MingW32\bin\CMake2.8\bin\msvcr90.dll >> >> You see, during installation of some packages, they add their '.\bin' >> first in the PATH. Thus potentially shadowing old DLLs for up-to-date >> system-dlls (and adding to the DLL-hell). That was the case with CMake >> above before I moved it's '.\bin' further up the PATH. >> > >This is the prescribed method if your application is dependent on the >version of DLL. A new version of the DLL may break your application. >So using a newer version of a DLL for an application that ships with >an older version isn't a good thing. However, since the DLL actually >resides in the directory with the application it should be used >regardless of PATH as long as you don't delete the DLL. The DLL-hell >is the reason for the implementation of manifest files. You can also >create a directory foo.exe.local and store your DLL in that directory >that foo.exe depends on. > >-- >Earnie >-- https://sites.google.com/site/earnieboyd > >------------------------------------------------------------------------------ >Try before you buy = See our experts in action! >The most comprehensive online learning library for Microsoft developers >is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >Metro Style Apps, more. Free future releases when you subscribe now! >http://p.sf.net/sfu/learndevnow-dev2 >_______________________________________________ >MinGW-users mailing list >Min...@li... > >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:min...@li...?subject=unsubscribe > > > |
From: Sam M. <sa...@re...> - 2012-02-01 10:33:43
|
On Sat, 28 Jan 2012 15:31:40 +0100, Gisle Vanem wrote: > "Jim Michaels" <jmi...@ya...> wrote: > >> Sat 01/28/2012 1:33:02.56|C:\WINDOWS\system32|>\u\which msvcrt80.dll >> msvcrt80.dll not found in ( >> C:\Program Files\PHP\ > > A tool that checks along the %PATH and report what's not there is not > so useful IMHO. Please try my 'envtool' program that reports where things > are and where things shouldn't be. E.g. the output here: > > G:\MingW32\src\inet\dsniff-2.4b2> envtool --path msvcr9*.dll > > Tue Jul 29 07:05:08 2008 : f:\windows\system32\msvcr90.dll > Tue Jul 29 07:05:08 2008 : f:\windows\system32\msvcr90d.dll That is not right. msvc[rp][89]0d?.dll, should not be in your system32 directory. They are only supposed to be deep within the SXS cache. If you know which bit of software dumped them in there then please let the authors know that they are not installing the redistributables correctly. If you put them in there yourself to get a specific program working, you should instead install them as 'private assemblies' in the directory of the EXE that requires them (details on MSDN). NB, this information does not apply to msvcr70.dll and friends, which pre- date the SXS mess, and msvcr10.dll, which has moved away from using SXS at all. Oh, I noticed that you are not the person with the original problem. Still, this advice may save you some hair pulling if you ever have problems caused by these DLLs being in the wrong place in the future. -- Sam Morris |
From: Earnie B. <ea...@us...> - 2012-02-01 12:29:24
|
On Wed, Feb 1, 2012 at 5:33 AM, Sam Morris wrote: > NB, this information does not apply to msvcr70.dll and friends, which pre- > date the SXS mess, and msvcr10.dll, which has moved away from using SXS > at all. Sam, did you mean msvcr100.dll instead of msvcr10.dll? -- Earnie -- https://sites.google.com/site/earnieboyd |