如何构建 libjpeg 9b 的 DLL 版本? [英] How to build a DLL version of libjpeg 9b?
问题描述
我想构建一个 DLL 版本的 libjpeg 9b.根据文档这里，看来我们需要添加一个预处理器 __declspec(dllexport) 或 __declspec(dllimport) 在每个要导出的函数的声明之前，除了将 Configuration Type 设置为Dynamic Library (.dll)".但这并不是一件容易的事，因为libjpeg 中的函数太多了.那么，是否有任何捷径或变通方法可以在不修改 jpeglib.h 或几乎不修改 jpeglib.h 的情况下构建 DLL libjpeg?是否有任何可用的 libjpeg 9b 的 DLL 就绪源?我在 Windows 7 64 位上使用 Visual Studio 2015.感谢您的回答.
PS:我从 http://www.ijg.org/files/下载了 libjpeg 9b 的源代码.这是官方下载的地方吗?我问是因为 .vcxproj(最初是 .v10)文件的开头字节似乎无效(C2 8B C2 AF C2 A8)所以 Visual Studio 无法打开它.
在 [GitHub]: CristiFati/Prebuilt-Binaries - (master) Prebuilt-Binaries/LibJPEG.
与当今几乎所有的软件一样，libjpeg 也托管在 [GitHub]:winlibs/libjpeg - libjpeg-9b.我从两个地方都下载了它，进行了比较，只发现了一些细微的差异(源代码中没有).我将在 GitHub 版本上进行解释.不幸的是，没有这方面的演练，所以我不得不查看一些文件以找出必须完成的工作.以下是步骤列表:
1.准备地面
1st 就是把压缩的 (zip/tar.gz) 文件内容解压到一个文件夹中(并有一个 cmd 控制台在那里打开).该文件夹包含一堆文件.我们需要的第一个st是makefile.vc.顾名思义，它是一个 Makefile，由一系列通常用于构建内容的规则/指令组成.
请注意，我正在使用 VStudio (Community) 2015 (14.0) 来完成这项任务(但应该没有区别对于较新的版本).
处理 Makefile 的工具是 nmake ([MS.Docs]:NMAKE 参考).我们需要针对该文件调用它.nmake 位于%VSTUDIO_INSTALL_DIR%VCin make.exe"(环境变量实际上并不存在，它只是一个路径占位符)；通常是%SystemDrive%Program Files (x86)Microsoft Visual Studio 14.0VCin make.exe"(例如在我的机器上它是 C:Installx86MicrosoftVisual Studio Community2015VCin make.exe").
请注意，在使用 VStudio 命令行工具时，最好是:
- 使用vcvarsall(这是一个(batch)工具，用于设置一些环境变量，例如%PATH%，%INCLUDE%、%LIB%、...)，因此所有 VStudio 工具都可以使用，但没有完整路径.但由于它也位于%VSTUDIO_INSTALL_DIR%VCvcvarsall.bat"中，因此不值得费力定位/调用它
- 从开始菜单(基本上调用vcvarsall)使用VS2015 Tools Command Prompt
- [MS.Docs]:在命令行上构建 包含有关此主题的更多详细信息
既然我们知道了 nmake 的位置，让我们运行:
"%VSTUDIO_INSTALL_DIR%VCin
make.exe"/f makefile.vc setup-v10(不要忘记将 nmake 的路径包含在 dblquotes(") 中，特别是如果它包含 SPACEs).
如果遇到问题，Google 可能会提供解决方案:
致命错误 U1052:找不到文件win32.mak"-在上图中，有 jpeg 项目设置窗口，显示了它们最后的样子.我突出显示(使用颜色)不同的兴趣点:
蓝色:平台/配置对:
- 正在修改(在最顶部的对话框中)
- 活动(在后面的 VStudio 主窗口中)
修改一些平台/配置设置时确保它是活动的(蓝色矩形中的数据相同)，否则你会用头撞墙，浪费时间去弄清楚为什么看起来正确的事情没有按预期工作.在我看来，当这个对话框弹出时，它应该有 active 值，但情况并非总是如此.
- 红色:应该修改(或至少需要注意)的项目:
- Configuration Type 显然应该是 Dynamic Library (.dll)
- 平台工具集应该是Visual Studio 2015(我提到这个，因为它碰巧用打开了一个VStudio 2010项目>VStudio2015，它保留了旧的工具集，并继续使用它进行构建，但前提是您同时安装了两个版本)
- 绿色:建议修改的项目.那些只是文件夹.请注意
$(Platform)变量(我将其用作一种很好的做法)，它在为 1 个以上的平台(例如 Win32 和 x64)
保存所有并构建.构建成功后，会出现一个新文件夹Win32-Release-DLL，和之前的一样，里面有一堆文件plus jpeg.dll.人们可能认为它已经完成了，但事实并非如此.所有代码都在 .dll 中编译/构建，但它未导出，所以 .dll 是几乎无法使用.您可以使用 依赖沃克.您可以查看 [SO]:Excel VBA，无法从 DLL 文件中找到 DLL 入口点(@CristiFati 的回答) - 在我们的例子中，导出区域为空.
最后一点:如果您认为将来需要为其他平台(x64，甚至 ARM)，并且你还需要做一些调试(添加一个Debug配置)，在Win32平台下添加Debug配置首先，然后然后从Win32创建新平台，否则您需要为每个平台添加调试配置在将 Debug 配置添加到 Win32 之前创建.
2.2 从 DLL
导出数据请注意:除了 __declspec(dllexport) 方法之外，还有 2 个方法(处理来自 Win 的导出时.dlls):
- 将导出列表作为参数传递给链接器 ([MS.Docs]:/EXPORT(导出函数))
- 在 [MS.Docs] 中枚举它们: 模块定义文件
但是，由于我们不知道代码并且可能有很多符号要导出，因此这 3 个中的任何一个都不是可扩展的(它们可能需要大量研究/工作).无论如何，我们将坚持原来的方法:
保存以下代码:
#pragma once#如果已定义(_WIN32)# 如果定义(LIBJPEG_STATIC)# 定义 LIBJPEG_EXPORT_API# 别的# 如果定义(LIBJPEG_EXPORTS)# 定义 LIBJPEG_EXPORT_API __declspec(dllexport)# 别的# 定义 LIBJPEG_EXPORT_API __declspec(dllimport)# 万一# 万一#别的# 定义 LIBJPEG_EXPORT_API#万一在 libjpeg 源文件夹中名为 jexport.h 的文件中.这是一个非常标准的头文件，用于处理.dll导出.
接下来，将其添加到项目中:在解决方案资源管理器中，RClick Header Files -> Add -> Existing Item...使用新文件
--- jmorecfg.h.orig 2016-03-30 09:38:56.000000000 +0300+++ jmorecfg.h 2017-06-09 21:04:33.762535400 +0300@@ -30,6 +30,8 @@* 在所有情况下(见下文).*/+#include "jexport.h"+#define BITS_IN_JSAMPLE 8/* 使用 8、9、10、11 或 12 */@@ -245,7 +247,8 @@/* 一个通过 EXTERN 引用的函数:*/#define GLOBAL(type) 类型/* 对全局函数的引用:*/-#define EXTERN(type) 外部类型++#define EXTERN(type) extern LIBJPEG_EXPORT_API 类型/* 这个宏用来声明一个方法"，也就是一个函数指针.以上是一个差异.请参阅 [SO]:从 PyCharm 社区版中的鼠标右键单击上下文菜单运行/调试 Django 应用程序的单元测试?(@CristiFati 的回答)(Patching utrunner 部分)了解如何在 Win 上应用补丁(基本上，以一个+"号进入，以一个-"号开头的每一行都退出).但是，由于更改是微不足道的，因此也可以手动完成.需要更改的文件是jmorecfg.h(需要两件事):
- 在开头包含新文件 (
#include "jexport.h") - 修改第 251 行(将
#define EXTERN(type) extern type替换为#define EXTERN(type) extern LIBJPEG_EXPORT_API type)
我认为这一步是一种解决方法(gainarie)，但正如我所说，真实的东西"只是需要太多的工作(和时间).
莉>- 在开头包含新文件 (
告诉编译器考虑我们的更改
编辑项目设置(再次注意平台/配置)，选择配置属性 -> C/C++ -> 预处理器 -> 预处理器定义 并将旧值(在我的情况下:WIN32;NDEBUG;_LIB;_CRT_SECURE_NO_WARNINGS)替换为 WIN32;LIBJPEG_EXPORTS;_CRT_SECURE_NO_WARNINGS;NDEBUG.我所做的是:
- 删除 _LIB
- 添加 LIBJPEG_EXPORTS
- 有些变化
[MS.文档]:/D(预处理器定义) 可能包含一些有用的信息.
作为旁注，经过上述更改后，原始(或正常")行为(Release 配置)将不会OK(它会生成一堆警告，但这在技术上是不正确的).那是因为我不想依赖 _LIB 宏来区分静态/动态库构建.为了解决这个问题，在预处理器定义中为发布配置添加LIBJPEG_STATIC(遵循与上面相同的过程).
保存所有并构建.构建成功后，覆盖jpeg.dll，更重要的是:一个新文件jpeg.lib会被创建；这告诉我们 jpeg.dll 导出某些东西.您可以使用 Dependency Walker 再次检查.
3.测试 DLL
- 这是可选的，我这样做是为了确保到目前为止我所做的没有白费
- 通过测试，我只指构建和运行，这意味着我不做任何功能测试(从 .dll 导出的函数实际上做了任何它们应该)
加载 apps.sln 解决方案，最好是在新的 VStudio 实例中.正如我所说，我只关心 djpeg 项目.
1st 要做的就是为现有的Release 配置构建它.但是，由于对jpeg 库所做的更改，它不会构建OOTB(会有链接器 错误).为了摆脱它们，编辑它的设置，预处理器定义(就像在上一步中一样)，并添加LIBJPEG_STATIC(不要忘记分隔符(<强>;)).
构建应该成功并且在 djpegRelease 文件夹下，应该有一个 djpeg.exe 文件.尝试运行它，会成功(这是我唯一关心的事情).
构建一个使用我们的 .dll 的新可执行文件:
- 就像在 jpeg 库的情况下一样，创建一个新配置:Release-DLL(确保执行所有步骤，但不要更改)莉>
- 只需要进行一项更改:让 链接器 知道我们在何处构建了 .lib 文件.进入项目设置，Configuration Properties -> Linker -> Input -> Additional Dependencies:第一个st是Releasejpeg.lib.很明显，路径不正确，所以我们需要用Win32-Release-DLL替换Release(当然你可以使用VStudio宏(用于平台/配置)).可能会检查 [MS.Docs]:.Lib 文件作为链接器输入.
保存所有并构建.构建成功后，在djpegRelease-DLL下，应该有一个djpeg.exe文件.尝试运行它会失败，因为它找不到jpeg.dll.通过将 jpeg.dll 复制到(检查 [MS.Docs]:语义的动态链接库搜索顺序):
- djpeg.exe 的文件夹
- %PATH% 环境变量中的一个文件夹(或者相反，将 jpeg.dll 文件夹附加到 %PATH%)
同样，您可以使用 Dependency Walker 检查 2 个可执行文件(但大小差异足以说明:2nd djpeg.exe 是明显更小)，看看哪个取决于 jpeg.dll.无论如何，这是我电脑上的输出(是的，Dependency Walker 也可以用作 cmdline :)):
<块引用>e:WorkDevStackOverflowq044450813srclibjpeg-libjpeg-9b>"c:Installx86DependsDependency Walker-politist-texanAllVersdepends.exe"/c/ot:static.txt djpegReleasedjpeg.exee:WorkDevStackOverflowq044450813srclibjpeg-libjpeg-9b>"c:Installx86DependsDependency Walker-politist-texanAllVersdepends.exe"/c/ot:dynamic.txtdjpegRelease-DLLdjpeg.exee:WorkDevStackOverflowq044450813srclibjpeg-libjpeg-9b>type static.txt |findstr -i "jpeg.dll"e:WorkDevStackOverflowq044450813srclibjpeg-libjpeg-9b>type dynamic.txt |findstr -i "jpeg.dll"[ ] e:workdevstackoverflowq044450813srclibjpeg-libjpeg-9bdjpeg elease-dllJPEG.DLL[ ] e:workdevstackoverflowq044450813srclibjpeg-libjpeg-9bdjpeg elease-dllJPEG.DLL 2017-06-09 21:16 2017-06-09 21:16 237,0500003000x000xx86 GUI CV，未知 0x10000000 未知 0x0003E000 未加载 N/AN/A 0.0 14.0 6.0 6.0
<小时>更新#0
我也:
- 提交对[GitHub]: winlibs/libjpeg - Win: 构建 libjpeg 的更改作为 dll(被拒绝)
- 尝试联系 JPEG 参考(多次)，但在点击 SEND<后表单冻结了/em>(一夜之间没有走运)
I want to build a DLL version of libjpeg 9b. According to the document here, it seems that we need to add a preprocessor
__declspec(dllexport)or__declspec(dllimport)before the declaration of each function to be exported, in addition to setting the Configuration Type to "Dynamic Library (.dll)". But this is not an easy job because there are so many functions in libjpeg. So, is there any short-cut or work-around to build a DLL libjpeg without or with little modification of the jpeglib.h? Is there any DLL-ready source of libjpeg 9b available? I am using Visual Studio 2015 on Windows 7 64bit. Thanks for your answer.PS: I downloaded the source of libjpeg 9b from http://www.ijg.org/files/. Is this the official place to download it? I ask because the beginning bytes of .vcxproj (originally .v10) files seems invalid (C2 8B C2 AF C2 A8) so Visual Studio is unable to open it.
解决方案Published builds (static / dynamic) on [GitHub]: CristiFati/Prebuilt-Binaries - (master) Prebuilt-Binaries/LibJPEG.
Like almost all of the nowadays software, libjpeg is also hosted on [GitHub]: winlibs/libjpeg - libjpeg-9b. I downloaded it from both places, did a comparison and only few minor differences (out of which none in the source code) popped up. I'm going to explain on the GitHub version. Unfortunately, there is no walkthrough on this, so I had to look inside some of the files in order to figure out what has to be done. Here's a list of steps:
1. Prepare the ground
1st thing is to extract the compressed (zip / tar.gz) file content into a folder (and have a cmd console opened there). That folder contains a bunch of files. The 1st one that we need is makefile.vc. As it name suggests, it's a Makefile that consists of a series of rules/instructions used in general to build stuff.
As a remark, I'm using VStudio (Community) 2015 (14.0) for this task (but there should be no differences for newer versions).
The tool that deals with Makefiles is nmake ([MS.Docs]: NMAKE reference). We need to call it against that file. nmake is located in "%VSTUDIO_INSTALL_DIR%VCin make.exe" (the env var doesn't really exist, it's just a path placeholder); typically that is "%SystemDrive%Program Files (x86)Microsoft Visual Studio 14.0VCin make.exe" (e.g. on my machine it's "C:Installx86MicrosoftVisual Studio Community2015VCin make.exe").
Note that when dealing with VStudio command line tools, it's better to either:
- Use vcvarsall (that's a (batch) tool that sets some env vars like %PATH%, %INCLUDE%, %LIB%, ...), so all the VStudio tools are available without their full path. But since it's also located in "%VSTUDIO_INSTALL_DIR%VCvcvarsall.bat", it doesn't worth the effort to locate/call it
- Use VS2015 Tools Command Prompt from Start Menu (which basically calls vcvarsall)
- [MS.Docs]: Building on the Command Line contains more details on this topic
Now that we know where nmake is located, let's run:
"%VSTUDIO_INSTALL_DIR%VCin make.exe" /f makefile.vc setup-v10(don't forget to enclose nmake's path in dblquotes("), especially if it contains SPACEs).
If running into issues, Google will probably yield solutions:
fatal error U1052: file 'win32.mak' not found- [MSDN.Social]: ntwin32.mak not found
setup-v10 is a Makefile target, which simply renames some of the files in the folder (frankly, I don't know why the files aren't like already renamed in the 1st place).
After running the command in the folder, there should be 2 VStudio solution files:
- jpeg.sln - which contains one project:
- jpeg.vcxproj - this is the project responsible of building the lib
- apps.sln - which contains a bunch of projects (which I don't know/care what they do):
- djpeg.vcxproj - this is the only one that I'm going to mention, since I'll be using it to test the built lib
2. Build the jpeg library
The 1st thing to notice is that the solution/project files generated in the previous section are for VStudio 2010. But that's not a problem, since VStudio 2015 is able to handle them (when loading them, it will do all the necessary conversions to bring them up to date).
Opening jpeg.sln, will reveal some (unpleasant) stuff about the solution (and project):
- It only has Win32 (32bit or x86) platform
- It only has Release configuration
- As you already mentioned, it builds a static library
Anyway, the solution should build OOTB. After completion, you'd notice a Release folder which should contain (besides a bunch of intermediary - .obj files), a 4+ MB jpeg.lib file which is the static lib. Knowing that the code (and project related files) is OK, let's move on to the next step.
2.1 Build the jpeg DLL
In order to avoid breaking existing functionality, we should create a new configuration (note that the process of creating a new platform for your project is (almost) the same):
- From menu, choose Build -> Configuration Manager...
- In the dialog box that popped, up click on the Release combo box and select < New...>
- In the New Solution Configuration dialog box, select a name for the new configuration: I chose Release-DLL (and from now on I'm going to rely on this name)
- Make sure to select Release in the Copy settings from combobox
- Check Create new project configurations
After pressing OK, the new the Release-DLL configuration will be identical to Release. Next step is to do the necessary changes to it, in order to achieve our goal. RClick on the jpeg project in the Solution Explorer (in the left side of VStudio window), and choose Properties:
In the image above, there's the jpeg project settings window, showing how they should look like at the end. I highlighted (using colors) different points of interest:
Blue: the Platform / Configuration pair:
- That is being modified (in the topmost dialog box)
- Active (in the VStudio main window in the back)
When modifying some Platform / Configuration settings make sure that it's the active one (the data in the blue rectangles is identical), otherwise you'd bang your head against the walls and waste time trying to figure out why something that seems correct, doesn't work as expected. On my opinion, when this dialog box pops up, it should have the active values, but that's not always the case.
- Red: items that should be modified (or at least require attention):
- Configuration Type should obviously be Dynamic Library (.dll)
- Platform Toolset should be Visual Studio 2015 (I'm mentioning this, since it happened to open a VStudio 2010 project with VStudio2015, and it kept the old toolset, and continued to build with it, but that's only if you have both versions installed)
- Green: items recommended to be modified. Those are only folders. Notice the
$(Platform)variable (that I use as a good practise), which comes in handy when building for more than 1 platform (e.g. Win32 and x64)
Save All and build. After the build succeeds, a new folder Win32-Release-DLL will appear, and like the previous one, it will contain a bunch of files plus jpeg.dll. One might think that it's done, but it's not quite so. All the code is compiled/built in the .dll, but it's not exported, so the .dll is pretty much unusable. You can check many of .dll (or .exe) properties opening it with Dependency Walker. You can look at the screenshots from [SO]: Excel VBA, Can't Find DLL Entry Point from a DLL file (@CristiFati's answer) - in our case the export area will be empty.
One final note: If you think that in the future you'll need to build for other platforms (x64, or even ARM), and also you'll need to do some debugging (add a Debug configuration), add the Debug configuration under Win32 platform first, and only then create the new platform from Win32, otherwise you'll need to add the Debug configuration for every platform created before adding the Debug configuration to Win32.
2.2 Export data from the DLL
Just as a note: besides the __declspec(dllexport) approach, there are 2 more (when dealing with exports from Win .dlls):
- Pass the export list as arguments to the linker ([MS.Docs]: /EXPORT (Exports a Function))
- Enumerate them in [MS.Docs]: Module-Definition Files
But, since we don't know the code and there might be many symbols to export, neither one of the 3 is scalable (they would probably require lots of research/work). Anyway, we'll stick to the original approach:
Save the following piece of code:
#pragma once #if defined(_WIN32) # if defined(LIBJPEG_STATIC) # define LIBJPEG_EXPORT_API # else # if defined(LIBJPEG_EXPORTS) # define LIBJPEG_EXPORT_API __declspec(dllexport) # else # define LIBJPEG_EXPORT_API __declspec(dllimport) # endif # endif #else # define LIBJPEG_EXPORT_API #endifin a file called jexport.h in the libjpeg source folder. This is a pretty standard header file that deals with .dll exports.
Next, add it to the project: in Solution Explorer, RClick on Header Files -> Add -> Existing Item...Make use of the new file
--- jmorecfg.h.orig 2016-03-30 09:38:56.000000000 +0300 +++ jmorecfg.h 2017-06-09 21:04:33.762535400 +0300 @@ -30,6 +30,8 @@ * in all cases (see below). */ +#include "jexport.h" + #define BITS_IN_JSAMPLE 8 /* use 8, 9, 10, 11, or 12 */ @@ -245,7 +247,8 @@ /* a function referenced thru EXTERNs: */ #define GLOBAL(type) type /* a reference to a GLOBAL function: */ -#define EXTERN(type) extern type + +#define EXTERN(type) extern LIBJPEG_EXPORT_API type /* This macro is used to declare a "method", that is, a function pointer.The above is a diff. See [SO]: Run/Debug a Django application's UnitTests from the mouse right click context menu in PyCharm Community Edition? (@CristiFati's answer) (Patching utrunner section) for how to apply patches on Win (basically, every line that starts with one "+" sign goes in, and every line that starts with one "-" sign goes out). But, since the changes are trivial, they can also be done manually. The file that needs to be changed, is jmorecfg.h (2 things are required):
- Include the new file at the beginning (
#include "jexport.h") - Modify line 251 (replace
#define EXTERN(type) extern typeby#define EXTERN(type) extern LIBJPEG_EXPORT_API type)
I consider this step some kind of a workaround (gainarie), but as I stated, the "real thing" would simply require too much work (and time).
- Include the new file at the beginning (
Tell the compiler to take our changes into account
Edit the project settings (again be careful with Platform / Configuration), select Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions and replace the old value (in my case: WIN32;NDEBUG;_LIB;_CRT_SECURE_NO_WARNINGS) to WIN32;LIBJPEG_EXPORTS;_CRT_SECURE_NO_WARNINGS;NDEBUG. What I did was:
- Removing _LIB
- Adding LIBJPEG_EXPORTS
- Some shifting
[MS.Docs]: /D (Preprocessor Definitions) might contain some useful info.
As a side note, after the above changes, the original (or "normal") behavior (Release configuration) will not be OK (it will build with a bunch of warnings, but that's not correct technically). That is because I didn't want to rely on the _LIB macro to differentiate between the static / dynamic library build. To straighten things out, add LIBJPEG_STATIC in the Preprocessor Definitions for Release configuration (following the same procedure as above).
Save All and build. After the build succeeds, the jpeg.dll is overwritten, and what's more important: a new file jpeg.lib will be created; that tells us that jpeg.dll exports something. You can check it again with Dependency Walker.
3. Test the DLL
- This is optional, I did it to be sure that what I did so far, was not in vain
- By tests, I only refer to building and running, meaning that I don't do any functional testing (the functions exported from the .dll actually do whatever they're supposed to)
Load the apps.sln solution, preferably in a new VStudio instance. As I said, I only care about the djpeg project.
1st thing to do, is to build it for the existing Release configuration. But, because of the changes done to jpeg library, it won't build OOTB (there will be linker errors). In order to get rid of them, edit its settings, the Preprocessor Definitions (just like in the previous step), and add LIBJPEG_STATIC (don't forget the separator (;)).
The build should be successful and under djpegRelease folder, there should be a djpeg.exe file. Attempting to run it, will succeed (and this is the only thing I care about).
Build a new executable that uses our .dll:
- Just like in jpeg library's case, create a new configuration: Release-DLL (make sure to do all the steps, but don't change it)
- There's only one change required: let the linker know where we built our .lib file. Go to project settings, Configuration Properties -> Linker -> Input -> Additional Dependencies: the 1st is Releasejpeg.lib. Obviously, the path is not correct, so we need to replace Release by Win32-Release-DLL (of course you could use VStudio macros (for Platform / Configuration)). Might check [MS.Docs]: .Lib Files as Linker Input.
Save All and build. After the build succeeds, under djpegRelease-DLL, there should be a djpeg.exe file. Attempting to run it will fail, since it can't find jpeg.dll. Fix that by either copying jpeg.dll to (check [MS.Docs]: Dynamic-Link Library Search Order for the semantics):
- The djpeg.exe's folder
- One of the folders that's in the %PATH% env var (or the other way around, append the jpeg.dll folder to %PATH%)
Again, you can check the 2 executables with Dependency Walker (but the size difference says enough: the 2nd djpeg.exe is significantly smaller), to see which one depends on the jpeg.dll. Anyway, here's the output on my computer (yes, Dependency Walker can act as a cmdline as well :) ):
e:WorkDevStackOverflowq044450813srclibjpeg-libjpeg-9b>"c:Installx86DependsDependency Walker-politist-texanAllVersdepends.exe" /c /ot:static.txt djpegReleasedjpeg.exe e:WorkDevStackOverflowq044450813srclibjpeg-libjpeg-9b>"c:Installx86DependsDependency Walker-politist-texanAllVersdepends.exe" /c /ot:dynamic.txt djpegRelease-DLLdjpeg.exe e:WorkDevStackOverflowq044450813srclibjpeg-libjpeg-9b>type static.txt | findstr -i "jpeg.dll" e:WorkDevStackOverflowq044450813srclibjpeg-libjpeg-9b>type dynamic.txt | findstr -i "jpeg.dll" [ ] e:workdevstackoverflowq044450813srclibjpeg-libjpeg-9bdjpeg elease-dllJPEG.DLL [ ] e:workdevstackoverflowq044450813srclibjpeg-libjpeg-9bdjpeg elease-dllJPEG.DLL 2017-06-09 21:16 2017-06-09 21:16 237,056 A 0x00000000 0x0003ECC8 x86 GUI CV,Unknown 0x10000000 Unknown 0x0003E000 Not Loaded N/A N/A 0.0 14.0 6.0 6.0
Update #0
I've also:
- Submitted the changes to [GitHub]: winlibs/libjpeg - Win: build libjpeg as a dll (rejected)
- Tried to contact JPEG Reference (several times), but the form froze after hitting SEND (left it even overnight with no luck)
这篇关于如何构建 libjpeg 9b 的 DLL 版本?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
