[CMake] find_file() fails for specific file in C:/Windows/System32 - Why?

[David Cole]

It's because CMake is a 32-bit app running on Win64. Windows itself reports
to a 32-bit app that "kernel32.dll" is in C:/Windows/System32, even though
the one that's really loaded into a 32-bit app is actually located at
C:/Windows/SysWOW64.

So, yes. It's "expected." In an unexpected sort of way... :-)


On Thu, Jun 3, 2010 at 11:50 AM, Scott Fowler <s.fowler at tecplot.com> wrote:

>  Yes, it's 64-bit Windows 7.
>
>
>
> I removed problem the files from C:/Windows/System32 and placed them in
> C:/Windows/SysWOW64 and now they get found.  But they are reported as found
> in C:/Windows/System32.  Is this expected?
>
>
>
> Scott
>
>
>
> *From:* David Cole [mailto:david.cole at kitware.com]
> *Sent:* Wednesday, June 02, 2010 2:45 PM
> *To:* Scott Fowler
> *Cc:* cmake at cmake.org
> *Subject:* Re: [CMake] find_file() fails for specific file in
> C:/Windows/System32 - Why?
>
>
>
> Is it 64-bit Windows?
>
> What happens if you put those files in "C:\Windows\SysWOW64"?
>
> The command:
>
> dir /s /b "C:\Windows\kernel32.dll"
>
>
>
> will show you that there are actually many kernel32.dlls to be found within
> Windows nowadays...
>
>
>
>
>
> HTH,
>
> David
>
>
>
>
>
> On Wed, Jun 2, 2010 at 5:18 PM, Scott Fowler <s.fowler at tecplot.com> wrote:
>
> I'm using the 'fixup_bundle' capability for generating my installation
> package, but GetPrerequisites fails for a specific file, which is in
> C:/Windows/System32.  Other files in C:/Windows/System32 are found just
> fine.  I've detected that the problem is specifically with the find_file()
> call.
>
>
>
> # Example Code that illustrates the problem
>
> set (myfiles
>
>     kernel32.dll
>
>     mpich2mpi.dll
>
>     testfile.txt  #dummy file I added to System32 for testing purposes.
>
>     )
>
> set (dirs
>
>     "C:/Windows/System32"
>
>     "C:/TEMP"
>
>     )
>
> foreach(file ${myfiles})
>
>   set(rt "rt-NOTFOUND")
>
>   find_file(rt "${file}" ${dirs} NO_DEFAULT_PATH)
>
>   MESSAGE(STATUS "FILE: ${file}; RT: ${rt}")
>
> endforeach(file)
>
>
>
> Ouput:
>
> FILE: kernel32.dll; RT: C:/Windows/System32/kernel32.dll
>
> FILE: mpich2mpi.dll; RT: rt-NOTFOUND
>
> FILE: testfile.txt; RT: rt-NOTFOUND
>
>
>
> If I copy mpich2mpi.dll and testfile.txt to C:/TEMP, the find_file() call
> will find the files in C:/TEMP.
>
>
>
> So my question is why does find_file NOT find mpich2mpi.dll in System32,
> but it can find it in C:/TEMP.  Does find_file treat the System32 directory
> special somehow?  Is there a recommended work around to this issue?
>
>
>
> Thanks,
>
> Scott
>
>
>  ------------------------------
>
> This e-mail and any files transmitted with it are confidential and are
> intended solely for the use of the individual or entity to whom they are
> addressed. If you are NOT the intended recipient or the person responsible
> for delivering the e-mail to the intended recipient, be advised that you
> have received this e-mail in error and that any use, dissemination,
> forwarding, printing or copying this e-mail is strictly prohibited.
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
>
>
> ------------------------------
> This e-mail and any files transmitted with it are confidential and are
> intended solely for the use of the individual or entity to whom they are
> addressed. If you are NOT the intended recipient or the person responsible
> for delivering the e-mail to the intended recipient, be advised that you
> have received this e-mail in error and that any use, dissemination,
> forwarding, printing or copying this e-mail is strictly prohibited.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100603/0b47579a/attachment-0001.htm>