[Bug 59855] New: .configure script fails on system without "ln -s"
http://bugs.winehq.org/show_bug.cgi?id=59855 Bug ID: 59855 Summary: .configure script fails on system without "ln -s" Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: build-env Assignee: wine-bugs@list.winehq.org Reporter: depaoli.renzo@gmail.com Distribution: --- Running "../wine/configure --enable-win64" on a Debian 12 64-bit fails. The setup does not permit symbolic links, which is recognised by "configure". checking whether ln -s works... no, using cp -pR The configure fails with makedep: ../wine/tools/makedep.c:2900: output_install_commands: Assertion `cmd->files.count == 1' failed. Aborted (core dumped) config.status: error: could not create Makefile -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59855 --- Comment #1 from Renzo de Paoli <depaoli.renzo@gmail.com> --- Running "../wine/configure" on a Debian 12 32-bit fails. The setup does not permit symbolic links, which is recognised by "configure". checking whether ln -s works... no, using cp -pR The configure fails with makedep: ../wine/tools/makedep.c:2900: output_install_commands: Assertion `cmd->files.count == 1' failed. Aborted (core dumped) config.status: error: could not create Makefile -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59855 Renzo de Paoli <depaoli.renzo@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59855 Renzo de Paoli <depaoli.renzo@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |depaoli.renzo@gmail.com URL| |regression, source -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59855 Stian Low <wineryyyyy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy@gmail.com --- Comment #2 from Stian Low <wineryyyyy@gmail.com> --- Please provide commit for regression reference. Are you sure it's not caused by directory permissions issues? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59855 --- Comment #3 from Renzo de Paoli <depaoli.renzo@gmail.com> --- I can confirm that this is not due to directory permissions. Running the same with "ln -s" permitted, the configure script runs fine. It can easily be reproduced with Virtual Machine building on a host's SharedDrive. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59855 --- Comment #4 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Renzo de Paoli from comment #3)
I can confirm that this is not due to directory permissions. Running the same with "ln -s" permitted, the configure script runs fine.
It can easily be reproduced with Virtual Machine building on a host's SharedDrive.
I'm Debian 13 and never had an issues with "ln -s" as of latest wine-11.10-13289668fd1. Are you running something that changes Debian default "ln -s" permission? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59855 --- Comment #5 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Renzo de Paoli from comment #1) I seem to running configure in a similar manner. Adding --prefix to local path make any difference? ../wine_stianlow/configure --enable-archs=i386,x86_64 --prefix=/home/any/tmp/wine_stianlow_wow64_new_install --enable-archs may be ignored if building without new_wow64 support -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59855 Renzo de Paoli <depaoli.renzo@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |4de74b451961b06c3c651ad6adf | |0d6248d0caafb --- Comment #6 from Renzo de Paoli <depaoli.renzo@gmail.com> --- Regression test result same for both, 64-bit and 32-bit: 4de74b451961b06c3c651ad6adf0d6248d0caafb is the first bad commit commit 4de74b451961b06c3c651ad6adf0d6248d0caafb Author: Alexandre Julliard <julliard@winehq.org> Date: Fri Oct 24 12:29:12 2025 +0200 makedep: Install multiple files at once when possible. tools/makedep.c | 121 +++++++++++++++++++++++++++++++++----------------------- 1 file changed, 72 insertions(+), 49 deletions(-) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59855 --- Comment #7 from Renzo de Paoli <depaoli.renzo@gmail.com> --- (In reply to Stian Low from comment #5)
(In reply to Renzo de Paoli from comment #1)
I seem to running configure in a similar manner.
Adding --prefix to local path make any difference?
../wine_stianlow/configure --enable-archs=i386,x86_64 --prefix=/home/any/tmp/wine_stianlow_wow64_new_install
--enable-archs may be ignored if building without new_wow64 support
Hi Stian. I am not trying to run the new_WOW, but the old_WOW. Therefore not using --enable-archs=i386,x86_64. The prefix option does not have an effect, ../wine/configure --enable-win64 --prefix=/home/vbox/test & ../wine/configure --prefix=/home/vbox/test both fail, as before. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59855 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|regression, source | Keywords| |regression, source CC| |imwellcushtymelike@gmail.co | |m --- Comment #8 from Ken Sharp <imwellcushtymelike@gmail.com> --- So I can definitely recreate this (Ubuntu Noble) by nobbling my system: $ sudo chmod -x /bin/ln $ ./configure But, under what circumstances would this make sense? I guess the cp -pR should work on any system, but isn't this part of the Autoconf system? “Macro: AC_PROG_LN_S If ‘ln -s’ works on the current file system (the operating system and file system support symbolic links), set the output variable LN_S to ‘ln -s’; otherwise, if ‘ln’ works, set LN_S to ‘ln’, and otherwise set it to ‘cp -p’.” https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Particu... It doesn't mention -R, but I don't know what that means, if anything. man cp: -R, -r, --recursive copy directories recursively Is the recursion the issue? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59855 --- Comment #9 from Nikolay Sivov <bunglehead@gmail.com> --- It's not about symlinks being suddenly unavailable system-wide, it's more likely that reporter is building on a filesystem that doesn't support them. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59855 Renzo de Paoli <depaoli.renzo@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org --- Comment #10 from Renzo de Paoli <depaoli.renzo@gmail.com> --- (In reply to Nikolay Sivov from comment #9)
It's not about symlinks being suddenly unavailable system-wide, it's more likely that reporter is building on a filesystem that doesn't support them.
Good morning Nikolay. Correct, as I stated earlier, this scenario occurs when building from a VM on a host's shared drive, where by default symlinks are disabled. There are probably many other ways to emulate the effect. As mentioned, the configure script recognises that symlinks are not available, but apparently tries to use them anyhow. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59855 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |ecd90dd6f0a68614c61f69f3062 | |5fab66e449afe Resolution|--- |FIXED --- Comment #11 from Alexandre Julliard <julliard@winehq.org> --- It should be fixed by ecd90dd6f0a68614c61f69f30625fab66e449afe. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla