From: Cristiano S. <sum...@gm...> - 2012-10-20 01:36:02
|
I trying to compile the Postgresql 9.2.1 sources with msvcr100.a but the make process stopping with errors. If using the msvcrt.a from default gcc specs then do not get any errors. I have seen messages saying that using different versions of runtime will cause problems during execution. I checked that the Postgresql binaries from oficial site with depends.exe and I saw them using the msvcr100.dll for runtime. I intending to compile freetds and try mimic the oracle_fdw extension. That is why I trying switch runtimes. I have basic C knowledge and would like to know if I should try make those extensions use a static link or if should not worry if generate a freetds.dll that uses msvcrt.dll with new Postgresql? I have dumped the specs from gcc to a file and replaced the calls from msvcrt with following: *libgcc: %{mthreads:-lmingwthrd} -lmingw32 %{shared-libgcc:-lgcc_s} %{!shared-libgcc:-lgcc_eh} -lgcc -lmoldname100 -lmingwex -lmsvcr100 I started with a new clean mingw32 msys on a Windows XP 32bit host. Then instructed configure with following ./configure --prefix=/usr --enable-nls and instaled missing dependencies mingw-get install mingw32-gettext-bin mingw-get install mingw32-gettext-dev mingw-get install mingw32-libz mingw-get install msys-wget mingw-get install msys-locate Before the specs change it finished. I opened some mingw headers and found a macro __MSVCRT_VERSION__ so I cleaned source and invoked the following configure with highest version I could find in header 0x0800 CFLAGS="-D__MSVCRT_VERSION=0x0800" ./configure --prefix=/usr --enable-nls Now during the make it stopped with the linker error below: gcc -D__MSVCRT_VERSION=0x0800 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard zic.o ialloc.o scheck.o localtime.o -L../../src/port -Wl,--allow-multiple-definition -Wl,--as-needed -lpgport -lintl -lz -lm -lws2_32 -lshfolder -o zic.exe g:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../libmingwex.a(dirent.o): dirent.c:(.text+0x249): undefined reference to `__findnext' g:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../libmingwex.a(dirent.o): dirent.c:(.text+0x2a2): undefined reference to `__findfirst' I looked for symbols on the libraries msvcrt.a and msvcr100.a nm /mingw/lib/libmsvcrt.a | grep __findnext 0000000 T __findnexti64 0000000 I __imp___findnexti64 0000000 T __findnext64 0000000 I __imp___findnext64 0000000 T __findnext 0000000 I __imp___findnext nm /mingw/lib/libmsvcr100.a | grep __findnext 0000000 T __findnext64i32 0000000 I __imp___findnext64i32 0000000 T __findnext64 0000000 I __imp___findnext64 0000000 T __findnext32i64 0000000 I __imp___findnext32i64 0000000 T __findnext32 0000000 I __imp___findnext32 Should be a missing preprocessor macro to translate the __findnext call to __findnext32? Or some linker "alias" missing ? |
From: Eli Z. <el...@gn...> - 2012-10-20 08:10:08
|
> Date: Fri, 19 Oct 2012 22:35:56 -0300 > From: Cristiano Sumariva <sum...@gm...> > > gcc -D__MSVCRT_VERSION=0x0800 -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute > -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard > zic.o ialloc.o scheck.o localtime.o -L../../src/port > -Wl,--allow-multiple-definition -Wl,--as-needed -lpgport -lintl -lz -lm > -lws2_32 -lshfolder -o zic.exe > g:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../libmingwex.a(dirent.o): > dirent.c:(.text+0x249): undefined reference to `__findnext' > g:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../libmingwex.a(dirent.o): > dirent.c:(.text+0x2a2): undefined reference to `__findfirst' > > I looked for symbols on the libraries msvcrt.a and msvcr100.a > > nm /mingw/lib/libmsvcrt.a | grep __findnext > 0000000 T __findnexti64 > 0000000 I __imp___findnexti64 > 0000000 T __findnext64 > 0000000 I __imp___findnext64 > 0000000 T __findnext > 0000000 I __imp___findnext > > nm /mingw/lib/libmsvcr100.a | grep __findnext > 0000000 T __findnext64i32 > 0000000 I __imp___findnext64i32 > 0000000 T __findnext64 > 0000000 I __imp___findnext64 > 0000000 T __findnext32i64 > 0000000 I __imp___findnext32i64 > 0000000 T __findnext32 > 0000000 I __imp___findnext32 > > Should be a missing preprocessor macro to translate the __findnext call to > __findnext32? Try adding it to some header that is included by all the code that calls _findfirst/_findnext. You should probably add the same for _findnext and a similar macro for 'struct _finddata'. These macros should be conditioned on __MSVCRT_VERSION__'s value. |
From: Earnie B. <ea...@us...> - 2012-10-20 16:57:57
|
On Sat, Oct 20, 2012 at 4:09 AM, Eli Zaretskii wrote: >> Date: Fri, 19 Oct 2012 22:35:56 -0300 >> From: Cristiano Sumariva >> >> gcc -D__MSVCRT_VERSION=0x0800 -Wall -Wmissing-prototypes -Wpointer-arith >> -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute >> -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard >> zic.o ialloc.o scheck.o localtime.o -L../../src/port >> -Wl,--allow-multiple-definition -Wl,--as-needed -lpgport -lintl -lz -lm >> -lws2_32 -lshfolder -o zic.exe >> g:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../libmingwex.a(dirent.o): >> dirent.c:(.text+0x249): undefined reference to `__findnext' >> g:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../libmingwex.a(dirent.o): >> dirent.c:(.text+0x2a2): undefined reference to `__findfirst' >> >> I looked for symbols on the libraries msvcrt.a and msvcr100.a >> >> nm /mingw/lib/libmsvcrt.a | grep __findnext >> 0000000 T __findnexti64 >> 0000000 I __imp___findnexti64 >> 0000000 T __findnext64 >> 0000000 I __imp___findnext64 >> 0000000 T __findnext >> 0000000 I __imp___findnext >> >> nm /mingw/lib/libmsvcr100.a | grep __findnext >> 0000000 T __findnext64i32 >> 0000000 I __imp___findnext64i32 >> 0000000 T __findnext64 >> 0000000 I __imp___findnext64 >> 0000000 T __findnext32i64 >> 0000000 I __imp___findnext32i64 >> 0000000 T __findnext32 >> 0000000 I __imp___findnext32 >> >> Should be a missing preprocessor macro to translate the __findnext call to >> __findnext32? > > Try adding it to some header that is included by all the code that > calls _findfirst/_findnext. You should probably add the same for > _findnext and a similar macro for 'struct _finddata'. These macros > should be conditioned on __MSVCRT_VERSION__'s value. You probably also need to define WINVER to something more modern. 0x0500 is Windows 2000, 0x0501 is WINXP, 0x0502 is windows server 2003, 0x0600 is Vista, 0x0601 is Windows 7. You also need to specify the library with -lmsvcr100 during the link phase. __MSVCRT_VERSION__ will not be used in the 4.0 release of the Windows System Library code; I found it too confusing to use/support and have removed it. I am using HAVE_FOO where FOO is the name of the function in question combined with a filter for OS version since MSVCRT.DLL is often upgraded with newer functions but not all from a particular MSVC release. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Cristiano S. <sum...@gm...> - 2012-10-22 00:05:48
|
Evil(took my sunday afternoon to figure why,sniff) macro defined at _mingw.h and used at io.h was causing the undefined link symbol __findfirst and __findnext at libmingwex.a using #__MSVCRT_VERSION__ >= 0x0800 for msvcr100.dll. _mingw.h # ifdef __GNUC__ # define _CRTALIAS __CRT_INLINE __attribute__ ((__always_inline__)) # else # define _CRTALIAS __CRT_INLINE # endif and used at io.h #if __MSVCRT_VERSION__ >= 0x0800 #ifndef _USE_32BIT_TIME_T _CRTIMP intptr_t __cdecl __MINGW_NOTHROW _findfirst (const char* _v1, struct _finddata_t* _v2) { return(_findfirst64i32 (_v1,(struct _finddata64i32_t*)_v2)); } _CRTIMP int __cdecl __MINGW_NOTHROW _findnext (intptr_t _v1, struct _finddata_t* _v2) { return(_findnext64i32 (_v1,(struct _finddata64i32_t*)_v2)); } just replaced the _CRTALIAS to _CRTIMP as above and GCC got happy. Unfortunely now during application run windows popus missing _stat symbol at msvcr100.dll. Any hints on this? Should this changes be reported as a feature request to be updatedb on headers? Also the io.h has some spaghetti( not native speaker ) #if checks. Also those doubled code also defined wchar.h. Would be clear to write an aux header file and include on both io.h and wchar.h . |
From: Earnie B. <ea...@us...> - 2012-10-22 12:13:46
|
On Sun, Oct 21, 2012 at 8:05 PM, Cristiano Sumariva wrote: > Evil(took my sunday afternoon to figure why,sniff) macro defined at _mingw.h > and used at io.h was causing the undefined link symbol __findfirst and > __findnext at libmingwex.a using #__MSVCRT_VERSION__ >= 0x0800 for > msvcr100.dll. > > _mingw.h > # ifdef __GNUC__ > # define _CRTALIAS __CRT_INLINE __attribute__ ((__always_inline__)) > # else > # define _CRTALIAS __CRT_INLINE > # endif > > and used at io.h > > #if __MSVCRT_VERSION__ >= 0x0800 > #ifndef _USE_32BIT_TIME_T > _CRTIMP intptr_t __cdecl __MINGW_NOTHROW _findfirst (const char* _v1, struct > _finddata_t* _v2) { return(_findfirst64i32 (_v1,(struct > _finddata64i32_t*)_v2)); } > _CRTIMP int __cdecl __MINGW_NOTHROW _findnext (intptr_t _v1, struct > _finddata_t* _v2) { return(_findnext64i32 (_v1,(struct > _finddata64i32_t*)_v2)); } > > just replaced the _CRTALIAS to _CRTIMP as above and GCC got happy. > > Unfortunely now during application run windows popus missing _stat symbol at > msvcr100.dll. > Any hints on this? > > Should this changes be reported as a feature request to be updatedb on > headers? > Also the io.h has some spaghetti( not native speaker ) #if checks. > Also those doubled code also defined wchar.h. Would be clear to write an aux > header file and include on both io.h and wchar.h . The current code exists at http://mingw.git.sourceforge.net/git/gitweb.cgi?p=mingw/mingw.org-wsl;a=summary and has changed for 4.0. You can clone it via git clone git://mingw.git.sourceforge.net/gitroot/mingw/mingw.org-wsl (caution, the reminder at SF points to the generic repository and is empty; you must replace the repository name (the last element of the URI) with the repository you wish to clone). The _USE_32BIT_TIME_T Microsoft garbage is a bit convoluted. The best test case I found was in the tests for tclsh. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Earnie B. <ea...@us...> - 2012-10-22 12:17:57
|
On Sun, Oct 21, 2012 at 8:05 PM, Cristiano Sumariva wrote: > > Unfortunely now during application run windows popus missing _stat symbol at > msvcr100.dll. > Any hints on this? > For the hint on what to use: strings msvcr100.dll | grep _stat _stat32 _stat32i64 _stat64 _stat64i32 _statusfp _statusfp2 Use MSDN to decide. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2012-10-22 19:13:37
|
On 20/10/12 02:35, Cristiano Sumariva wrote: > I opened some mingw headers and found a macro __MSVCRT_VERSION__ so > I cleaned source and invoked the following configure with highest > version I could find in header 0x0800 > > CFLAGS="-D__MSVCRT_VERSION=0x0800" ./configure --prefix=/usr > --enable-nls But the symbol you need to define is *not* __MSVCRT_VERSION; it is __MSVCRT_VERSION__. Note the pair of trailing underscores; they are significant. You need: CFLAGS="-D__MSVCRT_VERSION__=0x0800" ./configure --prefix=/usr --enable-nls (and, FTR, you really should *not* be using --prefix=usr, in MinGW builds; you should prefer --prefix=/mingw or --prefix=/usr/local). On 22/10/12 01:05, Cristiano Sumariva wrote: > Evil(took my sunday afternoon to figure why,sniff) macro defined at > _mingw.h and used at io.h was causing the undefined link symbol __findfirst > and __findnext at libmingwex.a using #__MSVCRT_VERSION__ >= 0x0800 > for msvcr100.dll. > > _mingw.h > # ifdef __GNUC__ > # define _CRTALIAS __CRT_INLINE __attribute__ ((__always_inline__)) > # else > # define _CRTALIAS __CRT_INLINE > # endif There's nothing evil about that: it's simply a hint to GCC that inline expansion of a function declared as a _CRTALIAS really is desired, and that out-of-line expansions are to be avoided when practicable. > and used at io.h > > #if __MSVCRT_VERSION__ >= 0x0800 > #ifndef _USE_32BIT_TIME_T > _CRTIMP intptr_t __cdecl __MINGW_NOTHROW _findfirst (const char* _v1, > struct _finddata_t* _v2) { return(_findfirst64i32 (_v1,(struct > _finddata64i32_t*)_v2)); } > _CRTIMP int __cdecl __MINGW_NOTHROW _findnext (intptr_t _v1, struct > _finddata_t* _v2) { return(_findnext64i32 (_v1,(struct > _finddata64i32_t*)_v2)); } > > just replaced the _CRTALIAS to _CRTIMP as above and GCC got happy. If I'm interpreting you correctly, these were originally defined as _CRTALIASes, and you've redefined them as _CRTIMPs? That just seems fundamentally the wrong thing to do -- you *want* these to be defined as _CRTALIASes, so that every reference to (nonexistent) _findfirst() and/or _findnext() is replaced inline, by corresponding references to the actually existing (exported by MSVCR100.DLL) _findfirst64i32() and _findnext64i32() respectively. By changing the _CRTALIAS to _CRTIMP, on a function *definition*, you are now telling GCC to emit a *public* symbol of that name, within every translation unit which includes io.h, and in which that defining statement is expanded. That simply cannot be correct; I'm amazed that your link didn't choke on multiply defined public symbols. > Unfortunely now during application run windows popus missing _stat > symbol at msvcr100.dll. Any hints on this? Once again, there needs to be a _CRTALIAS in scope, so _stat() is mapped to the appropriate MSVCR100.DLL replacement function. > Should this changes be reported as a feature request to be updatedb > on headers? No, because they seem to be inappropriate. > Also the io.h has some spaghetti( not native speaker ) #if checks. Agreed, it is a rather convoluted mess, but I believe that it is fundamentally correct. For example, this code (as foo.c): #include <io.h> int main() { struct _finddata_t foo; return (int)(_findfirst( "foo.*", &foo )); } when compiled with MinGW (with no header modifications): $ gcc -S -D__MSVCRT_VERSION__=0x0800 foo.c emits assembly code showing a direct call to __findfirst64i32, in place of the _findfirst() reference within the _main function; isn't this exactly what you would expect? > Also those doubled code also defined wchar.h. Would be clear to write > an aux header file and include on both io.h and wchar.h . Possibly, if you care enough to submit a patch for consideration. -- Regards, Keith. |
From: Cristiano S. <sum...@gm...> - 2012-10-23 01:52:32
|
That was a mail at typo, I used the macro you typed. A linker flag about multiple definitions was already set by postgresql build scripts: -Wl,--allow-multiple-definition Yes I could understand that the idea of _CRTALIAS was to generate a solution for the symbol using the macro expansion. But linker was still complaining about the missing symbol __findfirst undefined at libmingwex.a and I do not know why it was unable to translate the CRTALIAS macro expanded to the inline version and link properly. That why I posted here and glad to hear good lessons for the mingw. Unfortunely there is more in C that I could easily understand. I currently set the --prefix=/usr that is my common choice on a Linux station. I trying to build here in the same way that on a Linux terminal. Will replace to other path name. Better to learn more before try create a fix that do some useful changes. I will go the hints for the _stat case. |
From: Earnie B. <ea...@us...> - 2012-10-23 11:45:04
|
On Mon, Oct 22, 2012 at 9:52 PM, Cristiano Sumariva wrote: > > I currently set the --prefix=/usr that is my common choice on a Linux > station. When in Rome ... The common choice for MinGW is --prefix=/mingw. You will be happier with it. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Cristiano S. <sum...@gm...> - 2012-10-23 18:36:20
|
The common choice for MinGW is --prefix=/mingw you said. But that would not put new things into the <Drive>:/mingw/[bin|include|lib] paths ? There is algo same folders at <Drive>:/mingw/msys/1.0/[bin|include|lib]. And /usr map to <Drive>:/mingw/msys/1.0. The reason for this mapping is unknown to me. Why this separation? Not willing to put many question on list. Maybe on some topic on wiki but missed it. |
From: Earnie B. <ea...@us...> - 2012-10-23 19:22:38
|
On Tue, Oct 23, 2012 at 2:36 PM, Cristiano Sumariva wrote: > The common choice for MinGW is --prefix=/mingw you said. > But that would not put new things into the <Drive>:/mingw/[bin|include|lib] > paths ? > > There is algo same folders at <Drive>:/mingw/msys/1.0/[bin|include|lib]. > And /usr map to <Drive>:/mingw/msys/1.0. The reason for this mapping is > unknown to me. > > Why this separation? Not willing to put many question on list. Maybe on some > topic on wiki but missed it. The reasons are to distinguish from two different runtimes and build environments. The binaries and libraries in /mingw relate to the windows native runtime. Those in /mingw/msys/1.0 relate to the msys-1.0.dll runtime. Also, gcc will be able to locate without special instruction any libraries you build and install with a prefix of /mingw. Otherwise it has no idea where to find them unless you specify it. If I change to a MSYS build environment then I want the /usr/bin on PATH first and we have designed the environment initialization to set up the PATH appropriately. Only those programs dependent on msys-1.0.dll should be installed in /usr/* land to keep GCC happy. In MSYS /usr maps to the same directory as / does and that mapping is determined to be the parent directory of the directory contain the msys-1.0.dll. This mapping is not changeable by the user and is automatic. We by default deliver msys-1.0.dll in /mingw/msys/1.0/bin so /mingw/msys/1.0 relates to both / and /usr. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2012-10-23 19:50:04
|
On 23/10/12 02:52, Cristiano Sumariva wrote: > That was a mail at typo, I used the macro you typed. Okay. However, that you still then got a notification about an undefined '_findfirst' symbol reference tells me that some module in your project is being compiled without seeing that macro definition. > A linker flag about multiple definitions was already set by postgresql > build scripts: -Wl,--allow-multiple-definition I don't know if that works for Windows (PECOFF) objects; (it does appear to be documented among the generic options). However, that you even consider using it is a certain clue that you are doing something wrong. > Yes I could understand that the idea of _CRTALIAS was to generate a > solution for the symbol using the macro expansion. No, its intent is to *replace* references to a non-existent symbol, with references to a *different* (but equivalent) symbol, which does exist; it doesn't resolve the non-existent symbol. > But linker was still complaining about the missing symbol __findfirst > undefined at libmingwex.a and I do not know why it was unable to translate > the CRTALIAS macro expanded to the inline version and link properly. Welcome to Microsoft DLL hell! The only viable explanation is that the required macro definition was not in scope, within the translation unit which includes the _findfirst reference, when that was compiled. Looking back to your original post, I see that this reference is within libmingwex.a's dirent.o module; that certainly will not have been compiled to co-operate with anything other than MSVCRT.DLL; if you insist on migrating to non-system DLLs, and eliminating all dependencies on the standard system DLLs, then you may need to recompile some of the compiler support libraries, to make them compatible. -- Regards, Keith. |
From: JonY <jo...@us...> - 2012-10-23 22:07:58
Attachments:
signature.asc
|
On 10/23/2012 21:16, Keith Marshall wrote: > On 23/10/12 02:52, Cristiano Sumariva wrote: >> A linker flag about multiple definitions was already set by postgresql >> build scripts: -Wl,--allow-multiple-definition > > I don't know if that works for Windows (PECOFF) objects; (it does appear > to be documented among the generic options). However, that you even > consider using it is a certain clue that you are doing something wrong. I can't think of anything more wrong than doing this when you are having multiple runtime involved. Objects and opaque pointers from one aren't necessarily compatible with each other, so your program could crash at random. postgresql is doing something awfully wrong if they set it by default. |