difference between cygwin32 and cygwin64 mounts breaks libtool

difference between cygwin32 and cygwin64 mounts breaks libtool

[Bruno Haible]

[-- Attachment #1: Type: text/plain, Size: 5573 bytes --]

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 #2: wrapper-output.txt --]
[-- Type: text/plain, Size: 6181 bytes --]

C:\cygwin64\home\bruno\libiconv-1.15\build-cygwin32\src>.\iconv_no_i18n.exe --help
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:230: libtool wrapper (GNU libtool) 2.4.6
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:231: (main) argv[0]: ./iconv_no_i18n
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:232: (main) program_name: iconv_no_i18n
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:393: (find_executable): ./iconv_no_i18n
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:348: (check_executable): /cygdrive/c/cygwin64/home/bruno/libiconv-1.15/build-cygwin32/src/./iconv_no_i18n
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:237: (main) found exe (before symlink chase) at: /cygdrive/c/cygwin64/home/bruno/libiconv-1.15/build-cygwin32/src/./iconv_no_i18n
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:500: checking path component for symlinks: /cygdrive/c/cygwin64/home/bruno/libiconv-1.15/build-cygwin32/src/./iconv_no_i18n
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:500: checking path component for symlinks: /cygdrive/c/cygwin64/home/bruno/libiconv-1.15/build-cygwin32/src/.
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:500: checking path component for symlinks: /cygdrive/c/cygwin64/home/bruno/libiconv-1.15/build-cygwin32/src
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:500: checking path component for symlinks: /cygdrive/c/cygwin64/home/bruno/libiconv-1.15/build-cygwin32
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:500: checking path component for symlinks: /cygdrive/c/cygwin64/home/bruno/libiconv-1.15
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:500: checking path component for symlinks: /cygdrive/c/cygwin64/home/bruno
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:500: checking path component for symlinks: /cygdrive/c/cygwin64/home
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:500: checking path component for symlinks: /cygdrive/c/cygwin64
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:500: checking path component for symlinks: /cygdrive/c
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:500: checking path component for symlinks: /cygdrive
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:242: (main) found exe (after symlink chase) at: /cygdrive/c/cygwin64/home/bruno/libiconv-1.15/build-cygwin32/src/./iconv_no_i18n
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:265: (main) libtool target name: iconv_no_i18n.exe
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:616: (lt_setenv) setting 'BIN_SH' to 'xpg4'
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:616: (lt_setenv) setting 'DUALCASE' to '1'
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:666: (lt_update_exe_path) modifying 'PATH' by prepending '/usr/local/cygwin32/lib:/usr/local/cygwin32/bin:/home/bruno/libiconv-1.15/build-cygwin32/lib/.libs:'
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:616: (lt_setenv) setting 'PATH' to '/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'
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:687: (lt_update_lib_path) modifying 'PATH' by prepending '/home/bruno/libiconv-1.15/build-cygwin32/lib/.libs:'
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:616: (lt_setenv) setting 'PATH' to '/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'
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:297: (main) lt_argv_zero: /cygdrive/c/cygwin64/home/bruno/libiconv-1.15/build-cygwin32/src/./.libs/iconv_no_i18n.exe
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:301: (main) newargz[0]: /cygdrive/c/cygwin64/home/bruno/libiconv-1.15/build-cygwin32/src/./.libs/iconv_no_i18n.exe
iconv_no_i18n:./.libs/lt-iconv_no_i18n.c:301: (main) newargz[1]: --help
PATH=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


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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

Re: difference between cygwin32 and cygwin64 mounts breaks libtool

[cyg Simple]

On 11/18/2016 7:15 PM, Bruno Haible wrote:
> 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.
> 

This is a long standing collision and I don't think you'll be able to
get it to work as you want.  You might want to discuss with libtool list.

> 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?
> 

Short answer is no.  You're best scenario might be to have differing
/home paths and symlink the common files in one of them.  Otherwise
you're likely to end up with PATH that is overlapping and that doesn't work.

-- 
cyg Simple

--
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

Re: difference between cygwin32 and cygwin64 mounts breaks libtool

[Brian Inglis]

On 2016-11-20 12:01, cyg Simple wrote:
> On 11/18/2016 7:15 PM, Bruno Haible wrote:
>> 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.
> This is a long standing collision and I don't think you'll be able to
> get it to work as you want.  You might want to discuss with libtool list.
>> 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?
> Short answer is no.  You're best scenario might be to have differing
> /home paths and symlink the common files in one of them.  Otherwise
> you're likely to end up with PATH that is overlapping and that doesn't work.

Have you got LT_CYGPATH pointing to cygwin32 cygpath as described (or implied) in:
https://www.gnu.org/software/libtool/manual/html_node/Cygwin_002fWindows-File-Name-Conversion.html#Cygwin_002fWindows-File-Name-Conversion

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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

Re: difference between cygwin32 and cygwin64 mounts breaks libtool

[Bruno Haible]

Brian Inglis wrote in https://cygwin.com/ml/cygwin/2016-11/msg00259.html:
> Have you got LT_CYGPATH pointing to cygwin32 cygpath

Thanks for the suggestion, but alas:

- There is no cygwin32 cygpath in /usr/i686-pc-cygwin/sys-root/usr/bin.

- Letting LT_CYGPATH point to /usr/bin/cygpath.exe or
  C:\cygwin64\usr\bin\cygpath.exe does not change the symptom
  or fix the problem.

Bruno


--
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

Re: difference between cygwin32 and cygwin64 mounts breaks libtool

[Brian Inglis]

On 2016-11-23 10:09, Bruno Haible wrote:
> Brian Inglis wrote in https://cygwin.com/ml/cygwin/2016-11/msg00259.html:
>> Have you got LT_CYGPATH pointing to cygwin32 cygpath
> Thanks for the suggestion, but alas:
> - There is no cygwin32 cygpath in
> /usr/i686-pc-cygwin/sys-root/usr/bin.
> - Letting LT_CYGPATH point to /usr/bin/cygpath.exe or
> C:\cygwin64\usr\bin\cygpath.exe does not change the symptom or fix
> the problem.

If you want to run 32 bit code, you need to install cygwin32 in a
different directory e.g. c:/cygwin32/ and point LT_CYGPATH to
/proc/cygdrive/c/cygwin32/bin/cygpath. That is how you can use
cygwin32 cygwin1.dll, and access its 32 bit mount table, which was
part of your original question, and run 32 bit builds.

As the libtool docs explain, Cygwin64 cygpath is used to produce
the canonical Windows file name, then that is converted with
Cygwin32 cygpath to a POSIX filename in that environment.
You can not just magically run Cygwin32 code under Cygwin64
without the cygwin32 runtime dll(s) linked to the WoW dlls.

You could also run a straight build in that cygwin32 environment
without cross-compilation, using the same cygport build file as
64 bit. You are using cygport to simplify your Cygwin builds,
right?

In Linux environments, cygwin32 has to be installed under Wine,
and everything adapted to run Cygwin32 code under Wine, as
explained in the libtool docs mentioned:
https://www.gnu.org/software/libtool/manual/html_node/Cygwin_002fWindows-File-Name-Conversion.html#Cygwin_002fWindows-File-Name-Conversion
The alternative the docs say is to move the binaries to a
Cygwin32 environment for testing.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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

Re: difference between cygwin32 and cygwin64 mounts breaks libtool

[Brian Inglis]

On 2016-11-23 10:09, Bruno Haible wrote:
> Brian Inglis wrote in https://cygwin.com/ml/cygwin/2016-11/msg00259.html:
>> Have you got LT_CYGPATH pointing to cygwin32 cygpath
> Thanks for the suggestion, but alas:
> - There is no cygwin32 cygpath in
> /usr/i686-pc-cygwin/sys-root/usr/bin.
> - Letting LT_CYGPATH point to /usr/bin/cygpath.exe or
> C:\cygwin64\usr\bin\cygpath.exe does not change the symptom or fix
> the problem.

If you want to run 32 bit code, you need to install cygwin32 in a
different directory e.g. c:/cygwin32/ and point LT_CYGPATH to
/proc/cygdrive/c/cygwin32/bin/cygpath. That is how you can use
cygwin32 cygwin1.dll, and access its 32 bit mount table, which was
part of your original question, and run 32 bit builds.

As the libtool docs explain, Cygwin64 cygpath is used to produce
the canonical Windows file name, then that is converted with
Cygwin32 cygpath to a POSIX filename in that environment.
You can not just magically run Cygwin32 code under Cygwin64
without the cygwin32 runtime dll(s) linked to the WoW dlls.

You could also run a straight build in that cygwin32 environment
without cross-compilation, using the same cygport build file as
64 bit. You are using cygport to simplify your Cygwin builds,
right?

In Linux environments, cygwin32 has to be installed under Wine,
and everything adapted to run Cygwin32 code under Wine, as
explained in the libtool docs mentioned:
https://www.gnu.org/software/libtool/manual/html_node/Cygwin_002fWindows-File-Name-Conversion.html#Cygwin_002fWindows-File-Name-Conversion
The alternative the docs say is to move the binaries to a
Cygwin32 environment for testing.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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

Re: difference between cygwin32 and cygwin64 mounts breaks libtool

[Brian Inglis]

On 2016-11-23 10:09, Bruno Haible wrote:
> Brian Inglis wrote in https://cygwin.com/ml/cygwin/2016-11/msg00259.html:
>> Have you got LT_CYGPATH pointing to cygwin32 cygpath
> Thanks for the suggestion, but alas:
> - There is no cygwin32 cygpath in
> /usr/i686-pc-cygwin/sys-root/usr/bin.
> - Letting LT_CYGPATH point to /usr/bin/cygpath.exe or
> C:\cygwin64\usr\bin\cygpath.exe does not change the symptom or fix
> the problem.

If you want to run 32 bit code, you need to install cygwin32 in a
different directory e.g. c:/cygwin32/ and point LT_CYGPATH to
/proc/cygdrive/c/cygwin32/bin/cygpath. That is how you can use
cygwin32 cygwin1.dll, and access its 32 bit mount table, which was
part of your original question, and run 32 bit builds.

As the libtool docs explain, Cygwin64 cygpath is used to produce
the canonical Windows file name, then that is converted with
Cygwin32 cygpath to a POSIX filename in that environment.
You can not just magically run Cygwin32 code under Cygwin64
without the cygwin32 runtime dll(s) linked to the WoW dlls.

You could also run a straight build in that cygwin32 environment
without cross-compilation, using the same cygport build file as
64 bit. You are using cygport to simplify your Cygwin builds,
right?

In Linux environments, cygwin32 has to be installed under Wine,
and everything adapted to run Cygwin32 code under Wine, as
explained in the libtool docs mentioned:
https://www.gnu.org/software/libtool/manual/html_node/Cygwin_002fWindows-File-Name-Conversion.html#Cygwin_002fWindows-File-Name-Conversion
The alternative the docs say is to move the binaries to a
Cygwin32 environment for testing.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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