[
https://issues.apache.org/jira/browse/DAEMON-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825565#comment-16825565
]
Mark Thomas commented on DAEMON-401:
------------------------------------
Do you see the same issue if you use the Windows binaries provided by Apache
Commons?
We deliberately do no build directly from Visual Studio since that creates
dependencies on runtime libraries that may not be present on the target system
and we'd like to avoid the added complexity of shipping those runtime
dependencies.
We haven't done a great job documenting the build process. That is something we
can look to improve in the next release. The build environment is essentially
the same as Apache Tomcat:
[https://cwiki.apache.org/confluence/display/TOMCAT/Building+the+native+Tomcat+components+for+Windows]
Once that is set up, building is:
{code:java}
C:\cmsc\setenv.bat /x64
nmake -f Makefile{code}
> Environment variables set on service not available in JNI dll
> -------------------------------------------------------------
>
> Key: DAEMON-401
> URL: https://issues.apache.org/jira/browse/DAEMON-401
> Project: Commons Daemon
> Issue Type: Bug
> Reporter: Jonathan Gallimore
> Priority: Major
> Attachments: daemon-env.diff
>
>
> I have a JNI dll loaded by a Java process running as a Windows service on
> Windows 2019 using prunsrv. The JNI library is built with VC14, and makes
> calls to getenv(), which is imported from ucrtbase.dll.
> This call to getenv does not pick up environment variables that are set on
> the service via //US//Service ++Environment "key=value". Commons Daemon is
> setting these environment variables using _wputenv(), which is imported from
> msvcrt.dll.
> I started a discussion on the mailing list regarding this. I have patch which
> dynamically loads ucrtbase.dll and calls its _wputenv method as well, if it
> is available.
> I'm happy to provide changes or further patches, and work on this issue, but
> feedback would be useful and very much appreciated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
