GNOME Bugzilla – Bug 450052
gconfd-2.exe prefers DLLs from system directories to $prefix\bin
Last modified: 2018-06-29 21:40:05 UTC
Steps to reproduce: 1. Install version Gnucash 2.1.4 Win on Windows XP Home Edition 5.1.2600 2. Start application gnucash.bat 3. After few seconds Windows reports error: gconfd-2.exe - Entry Ponit Not Found The procedure entry point libiconv_set_relocation_prefix could not be located in the dynamic link library iconv.dll. Process gnucash-bin.exe remains active. Stack trace: Other information:
Could you please search for all files named "iconv.dll" on your system, please?
Thanx, I had some version in Windows directory. I renamed it and this solved the problem.
Welcome to DLL hell. I am not sure how we can fix this. Here is the plot: Search Path Used by Windows to Locate a DLL 1. The directory where the executable module for the current process is located. 2. The current directory. 3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory. 4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory. 5. The directories listed in the PATH environment variable. Our iconv.dll is in $PREFIX\bin. 1. gconfd-2.exe is in $PREFIX\libexec. We cannot move it because gconftool-2.exe will not find it anymore. 2. gconfd-2.exe is spawned implicitly, the current directory is not under our control. 3. Well... 4. Well... 5. We are too late. Any suggestions?
Adding another copy of iconv.dll to $prefix/libexec...?
I tried this, I put another copy of iconv.dll to $prefix/libexec, and the wrong one put back in WINDOWS directory, and it works fine. I guess that the redundancy of having iconv.dll both in $prefix\bin and $prefix/libexec wont make any problems.
However, we don't know whether iconv.dll is the only DLL that people might have in their win directories. You can easily imagine the same situation might happen with xyz.dll... and we can't copy *all* of our DLLs into many many places. Do you have any hint as to why iconv.dll existed in your system directory?
I can't be sure because there is no version information associated with this file, there is no version tab at all. (Unlike the file from $PREFIX\bin: LGPLed libiconv for Windows NT/2000/XP and Windows 95/98/ME etc) If I look on the date of creation of this file it looks almost as it came with image installation of my computer (Acer Aspire 5020 Series – 5024WLMi with AMD Turion processor) while date of creation is the same as the rest of files from installation image (2nd of April 2005) – the date of modification of this file is 24th of November 2003. The date of creation of this file is prior of installation of my laptop on 21st of December 2005. I can’t associate this file with any particular application.
Lowering the severity to normal. Christian, I fully agree to comment 4 and 6. Let us leave this open and hope for a brilliant idea someday :-)
*** Bug 453800 has been marked as a duplicate of this bug. ***
I also have bought recently an Acer Aspire (type 9420) with Vista and have the same problem as described above.
Created attachment 91302 [details] redirect.exe Could you please try the following: * resurrect your bad iconv.dll in your windows directory * move libexec\gconfd-2.exe to bin\ * save redirect.exe (attachment) to libexec\gconfd-2.exe * retry
Created attachment 91303 [details] [review] redirect.patch sources so far
Cstim, do you think that is a reasonable solution (provided that it works)? I would add mv commands to dist.sh then.
(In reply to comment #13) > Cstim, do you think that is a reasonable solution (provided that it works)? If it works then yes, this would be a nice solution. Will probably be needed for all *.exe that happen to exist outside of $prefix/bin, namely the qt3-wizard.exe as well. I'm a bit afraid about your comment of __wgetmainargs() being "undocumented" - does that function still exist on all target win systems?
I could not find any documentation for it. But as gspawn-win32-helper.exe depends on it, I guess we can do as well. This issue should be solved as of r16277 or GnuCash 2.1.6. If anyone tests it earlier by building from sources, this would be even better, of course.
*** Bug 456319 has been marked as a duplicate of this bug. ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=450052. Please update any external references or bookmarks.