This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi, Short summary: ============== When a user has installed cygwin64 and the cross-compilation environment for compiling to 32-bit cygwin (i686-pc-cygwin-gcc et al.), then building (with --host=i686-pc-cygwin) a package that creates a shared library and a program that uses this shared library - in different source directories - makes use of libtool features: The uninstalled program (i.e. the program in the build tree) is a wrapper program (built by libtool) that sets up PATH so that the real program should find the (uninstalled) shared library before invoking the real program. This works when building outside of C:\cygwin64 (for example, in C:\Users\bruno), but it does not work when building inside C:\cygwin64 (for example, in C:\cygwin64\home = /home). In this case, the uninstalled program exits with exit code 127. When this uninstalled program is run in a cmd.exe window, it prints a diagnostic message that mentions which shared library it could not find. Short question: =============== Is there a way to configure the mounts of the 32-bit cygwin subsystem and the mounts of the 64-bit cygwin so that this will work also in /home? Long explanation: ================= As described in http://lists.gnu.org/archive/html/bug-libtool/2016-10/msg00000.html I'm building a libiconv tarball in /home/bruno/libiconv-1.15. The build creates a shared library cygiconv-2.dll in lib/.libs/ and an executable src/iconv_no_i18n.exe - this is the wrapper program, a 32-bit Cygwin executable - as well as the real executable src/.libs/iconv_no_i18n.exe (also a 32-bit Cygwin executable, of course). For debugging: 1) I modified the 'libtool' script, changing #if defined LT_DEBUGWRAPPER to #if 1 2) I created a small 32-bit mingw program that prints the value of getenv("PATH") that was passed to it, and temporarily moved it to src/.libs/iconv_no_i18n.exe. With this debugging, I found that the src/iconv_no_i18n.exe (the wrapper script) sets PATH to the value [I have added the line breaks only for clarity] /home/bruno/libiconv-1.15/build-cygwin32/lib/.libs: /usr/local/cygwin32/lib: /usr/local/cygwin32/bin: /home/bruno/libiconv-1.15/build-cygwin32/lib/.libs: /usr/bin: /cygdrive/c/Program Files (x86)/Intel/iCLS Client: /cygdrive/c/Program Files/Intel/iCLS Client: /cygdrive/c/WINDOWS/system32: /cygdrive/c/WINDOWS: /cygdrive/c/WINDOWS/System32/Wbem: /cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0: /cygdrive/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/DAL: /cygdrive/c/Program Files/Intel/Intel(R) Management Engine Components/DAL: /cygdrive/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/IPT: /cygdrive/c/Program Files/Intel/Intel(R) Management Engine Components/IPT: /cygdrive/c/Program Files/Intel/WiFi/bin: /cygdrive/c/Program Files/Common Files/Intel/WirelessCommon: /cygdrive/c/Program Files (x86)/Windows Kits/8.1/Windows Performance Toolkit: /cygdrive/c/Users/bruno/AppData/Local/Microsoft/WindowsApps and that the invoked src/.libs/iconv_no_i18n.exe sees a PATH value of C:\cygwin64\usr\i686-pc-cygwin\sys-root\usr\home\bruno\libiconv-1.15\build-cygwin32\lib\.libs; C:\cygwin64\usr\i686-pc-cygwin\sys-root\usr\usr\local\cygwin32\lib; C:\cygwin64\usr\i686-pc-cygwin\sys-root\usr\usr\local\cygwin32\bin; C:\cygwin64\usr\i686-pc-cygwin\sys-root\usr\home\bruno\libiconv-1.15\build-cygwin32\lib\.libs; C:\cygwin64\usr\i686-pc-cygwin\sys-root\usr\bin; C:\Program Files (x86)\Intel\iCLS Client; C:\Program Files\Intel\iCLS Client; C:\WINDOWS\system32; C:\WINDOWS; C:\WINDOWS\System32\Wbem; C:\WINDOWS\System32\WindowsPowerShell\v1.0; C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL; C:\Program Files\Intel\Intel(R) Management Engine Components\DAL; C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT; C:\Program Files\Intel\Intel(R) Management Engine Components\IPT; C:\Program Files\Intel\WiFi\bin; C:\Program Files\Common Files\Intel\WirelessCommon; C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit; C:\Users\bruno\AppData\Local\Microsoft\WindowsApps The first 4 entries in this PATH are wrong: they reference nonexistent directories. For the program to find its cygiconv-2.dll the PATH would have to be C:\cygwin64\home\bruno\libiconv-1.15\build-cygwin32\lib\.libs; C:\cygwin64\usr\local\cygwin32\lib; C:\cygwin64\usr\local\cygwin32\bin; C:\cygwin64\home\bruno\libiconv-1.15\build-cygwin32\lib\.libs; C:\cygwin64\usr\i686-pc-cygwin\sys-root\usr\bin; C:\Program Files (x86)\Intel\iCLS Client; C:\Program Files\Intel\iCLS Client; C:\WINDOWS\system32; C:\WINDOWS; C:\WINDOWS\System32\Wbem; C:\WINDOWS\System32\WindowsPowerShell\v1.0; C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL; C:\Program Files\Intel\Intel(R) Management Engine Components\DAL; C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT; C:\Program Files\Intel\Intel(R) Management Engine Components\IPT; C:\Program Files\Intel\WiFi\bin; C:\Program Files\Common Files\Intel\WirelessCommon; C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit; C:\Users\bruno\AppData\Local\Microsoft\WindowsApps Now, how can I configure Cygwin so that it will not transform /home/bruno/foo/bar to C:\cygwin64\usr\i686-pc-cygwin\sys-root\usr\home\bruno\foo\bar but instead to C:\cygwin64\home\bruno\foo\bar ? IMO such a configuration should be the default when I install the cross-compilation environment. Bruno
Attachment:
wrapper-output.txt
Description: Text document
-- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |