https://bz.apache.org/ooo/show_bug.cgi?id=127731
--- Comment #11 from dam...@apache.org ---
(In reply to Matthias Seidel from comment #9)
> Funny fact:
>
> After building odbcconfig.exe in
>
> main\solver\420\wntmsci12.pro\bin
>
> starts without problem and shows the expected dialog.
If my theory is right, it would explain this as well.
Linking an "executable.exe" file, also generates an "executable.manifest" file.
dmake's build scripts have a step where they link the executable.manifest into
the executable.exe, eg. for uno.exe:
---snip---
linking ../../wntmsci12/bin/uno.exe.manifest ...
if [ -f ../../wntmsci12/bin/uno.exe.manifest ] ; then mt.exe -manifest
../../wntmsci12/bin/uno.exe.manifest
-outputresource:../../wntmsci12/bin/uno.exe\;1 ; fi
---snip---
gbuild's build scripts, however, do not use mt.exe, and instead copy the
manifest to the ${OUTDIR}/bin directory. From there, the manifest is NOT
PACKAGED (into instsetoo_native), resulting in no manifest in the release
binaries.
When a module is ported from dmake to gbuild, and you run eg. uno.exe or
Matthias's odbcconfig.exe from {OUTDIR}/bin, it works because the
uno.exe.manifest or odbcconfig.exe.manifest is also in that directory. However
in the release binaries in instsetoo_native, it won't work, because the
manifests aren't packaged.
If you copy uno.exe.manifest into the instsetoo_native directory where uno.exe
is, and try running uno.exe, it starts working. Rename uno.exe.manifest to
odbcconfig.exe.manifest, and odbcconfig.exe starts working.
Either we need to:
1. Link the manifest into the executable as a resource, and stop delivering it
into ${OUTDIR}, like dmake did.
2. Package the manifests along with their executables.
I think option 1 is clearer. It's unclear why gbuild tried to move to option 2.
--
You are receiving this mail because:
You are the assignee for the issue.
