some thoughts on win32 'make install'

Lubomir I. Ivanov neolit123 at gmail.com
Fri Oct 11 08:44:20 UTC 2013


On 11 October 2013 18:23, Thiago Macieira <thiago at macieira.org> wrote:
> On sexta-feira, 11 de outubro de 2013 18:06:40, Lubomir I. Ivanov wrote:
>> > That was my assumption too. The script runs quite well in the cross-build.
>> > One thing I didn't check: is C:\Windows\System32 on $PATH? Because if it
>> > is, the script I wrote will copy the Windows DLLs too and we don't want
>> > that.
>> yes, it is.
>
> I'll need to exclude it. We don't want to package those DLLs.
>
>> > I had actually never used $(SED). I first wrote a manual "sed", but then I
>> > noticed that the Makefile had the variable set, so I started using it.
>> >
>> > Feel free to change back to just "sed".
>>
>> there seems to be a problem with $(CC) as well. i don't think it
>> should be hardcoded?
>
> The CC variable should have been set at the beginning of the Makefile. How does
> any C source get compiled otherwise?

this is odd... the makefile has on top:
CC            = gcc
CXX           = g++

but if i don't set 'gcc' instead of $(CC) here:
dlls.commands += PATH=\$\$PATH:`$(CC) -print-search-dirs | sed -nE
\'/^libraries: =/{s///;s,/lib/?(:|\\\$\$),/bin\\1,g;p;q;}\'`

i get a:
/bin/sh: cc: command not found

this is the resulted line in the dll rule:
PATH=$$PATH:`$(CC) -print-search-dirs | sed -nE '/^libraries:
=/{s///;s,/lib/?(:|\$$),/bin\1,g;p;q;}'` perl
C:/dev/subsurface/scripts/win-ldd.pl $(DESTDIR_TARGET)
C:\bin\Qt\4.8.5\plugins/imageformats/qjpegd4.dll
-L/dev/linux_lib/libdivecomputer/lib -ldivecomputer-win32
-L/dev/linux_lib/libxml/lib -lxml2-2 -L/dev/linux_lib/libxslt/lib
-lxslt-1 -lmarblewidgetd -lwsock32 | while read name; do
$(INSTALL_FILE) $$name C:/dev/subsurface/packaging/windows; done

could be a bug in make.

>
>> > Change the latter part to:
>> >         die("$!");
>> >
>> > This will at least print the actual error. Maybe no objdump to be found in
>> > $PATH?
>>
>> my $objdump = $ENV{objdump} ? $ENV{objdump} : "i686-w64-mingw32-objdump";
>>
>> objdump is in PATH, but doesn't $ENV return the contents of an env.
>> variable named 'objdump'?
>> if so this would fail on windows, because there is not such variable.
>
> Oops, that was a left-over testing. I should have left it as "objdump" in the
> fallback case.
>
> Does it run if you change the third operand to "objdump"?

yes, it does.

>
>> > I'm assuming that you actually have subsurface.exe running, which means
>> > that all the DLLs must be found in $PATH. Any missing DLLs are silently
>> > discarded, since we don't want to package the ones that come with the
>> > system in C:\Windows\System32.
>> >
>> > I could change it so that it complains about missing DLLs except if they
>> > are in the system32 dir, but I'd need a solution for the cross-build
>> > packaging.
>>
>> i don't have the DLLs in PATH, so i copy the files where the .exe is,
>> which should be the first search location for a DLL, if i recall
>> correctly.
>
> Good point, I need to add that case too.
>
>> so we may have to instruct developers to copy all required DLL's in
>> folder that is in PATH, so that the perl script can find them (but
>> also subsurface).
>
> I'd hope this instruction is not necessary. Subsurface won't run unless all
> the DLLs are in PATH or next to the .exe. If I add the side-by-side case to
> the script, it should be enough.
>
>> the output for a missing DLL is a good idea.
>
> Yup. But I need a way to detect system DLLs that we don't want to ship and,
> thus, are allowed to be missing.
>

perhaps, if the DLL exists in PATH and the current scanned directory
from PATH contains "system32" in the name, then it's a system DLL and
should not be reported.

lubomir
--


More information about the subsurface mailing list