链接器错误:当我根本没有定义它时,它已经在我的项目中定义了

发布于 2024-10-08 20:34:58 字数 1265 浏览 3 评论 0原文

我正在尝试在 Visual C++ 2010 Express 中构建一个 C 项目作为 C++,以便我可以为其创建一个 C++/CLI .net 包装器。它编译得很好,但链接器告诉我 swprintf(...)、vswprintf(...)、_swprintf_l(...) 和 _vswprintf(...) 已经定义。奇怪的是,它说它们已经在我制作的 .obj 文件中定义,并且我确信我没有定义它们。事实上,我什至没有给他们任何一个打电话。有谁知道这可能是什么原因造成的?

一些澄清: 该库直接用 C 语言编写,并在 OS X、FreeBSD、OpenBSD 和 Linux 中构建和运行。将其作为 .net 程序集移植到 Windows 是一项挑战。我读到 C 库必须用 C++ 构建才能获得 C++/CLI 包装器。为了将其构建为 C++ 项目,我必须进行一些调整(例如 malloc 转换),但它仍应保持 C 兼容性。

* 最终更新 *

我不知道我浪费了多少时间来尝试为我正在编写的文件解析库制作 .net 包装器。我已经尝试过好几次了,但每次都以失败告终。这次我确实比以前走得更远,但我仍然无法让它发挥作用。

我最初设想的是一个 3 项目解决方案:

  1. 一个非托管静态库,用 C 构建
  2. 一个托管 .net 包装器,用 C++/CLI 构建
  3. 一个托管 winforms 应用程序,用 C# 构建

我很快了解到 Visual Studio 的 Express 版本为您提供了正是您为它们支付的费用,并且不允许您在单个解决方案中混合不同语言的项目。为了做到这一点,我必须为 VS Pro 支付 800 美元,但这并没有发生!

我决定用 C++/CLI 编写简单的应用程序来适应这一点。即便如此,它根本行不通。显然,我要么必须链接第 1 部分中的 .obj 文件(这不起作用,因为它无法使用 /clr 编译 C 文件),要么使用 /clr:safe 构建第 2 部分(这会产生各种其他问题) 。

我真的不知道这是否是无用的 VS Express 版本的限制,或者这是否可以通过昂贵的版本实现(奇怪的是 800 美元可以买到 VS Pro,但是 700 美元可以得到所有 XCode 和 Mac Mini)参加微软开发税?!?)但无论如何,我已经受够了。我的库在 OS X、FreeBSD、OpenBSD、Linux 和 OpenSolaris 上工作得很好,但在 Windows 上却不行,直到 MS 发布免费的开发工具,这些工具实际上很有用,并且实际上提供了一种使用可移植代码的方法(这适用于),我才赢了不在乎。

感谢所有提供建议并试图提供帮助的人。

乔吉

I am trying to build a C project in Visual C++ 2010 Express as C++ so I can create a C++/CLI .net wrapper for it. It compiles fine, but the linker tells me that swprintf(...), vswprintf(...), _swprintf_l(...), and _vswprintf(...) are already defined. The strange thing is that it says they are already defined in an .obj file that I made, and I am sure that I did not define them. In fact, I don't even call any of them. Does anyone have any idea what could be causing this?

Some clarifications:
This library is being written in straight C and built and run in OS X, FreeBSD, OpenBSD, and Linux. Porting it to Windows as a .net assembly is the challenge. I read that C libraries must be built in C++ to be given a C++/CLI wrapper. In getting it to build as a C++ project, I had to make a few tweaks (such as malloc casting) but it should still maintain C compatibility.

* FINAL UPDATE *

I don't know how many hours I have wasted trying to make a .net wrapper for the file parsing library I am writing. I have tried it several times and every time it fails miserably. This time I did get farther than ever before, but I still could not get it to work.

What I had originally envisioned was a 3 project solution:

  1. an unmanaged static libary, built in C
  2. a managed .net wrapper, built in C++/CLI
  3. a managed winforms app, built in C#

I quickly learned that the express editions of Visual Studio give you exactly what you pay for them and don't allow you to mix projects of different languages in a single solution. In order to do that, I would have to pay $800 for VS Pro and that is NOT happening!

I adapted to this by deciding to write the simple app in C++/CLI. Even so, it simply would not work. Apparently, I would either have to link the .obj files from part 1 (which doesn't work, because it cannot compile C files with /clr) or build part 2 with /clr:safe (which created all kinds of other problems).

I really don't know if this is a limitation of the useless Express editions of VS or if this would even be possible with the absurdly expensive versions (strange that $800 gets you VS Pro, but $700 gets you all of XCode and a Mac Mini to run in on! Microsoft Dev Tax anyone?!?) but either way, I've had enough. My library works great in OS X, FreeBSD, OpenBSD, Linux, and OpenSolaris, but not Windows, and until MS releases free dev tools that are actually useful and actually provide a way to use PORTABLE code (this works in), I just won't care.

Thanks to all of you who gave advice and tried to help.

jorj

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

呆° 2024-10-15 20:34:58

您可以检查所有项目和文件是否都使用相同的通用运行时库(属性 | C\C++)并检查运行时库设置。同时包含多线程调试 DLL (\MDd) CRT 和多线程 DLL(\MD) 或其他与 CRT 库的此类混合可能会导致类似的情况。

您可以发布链接器输出吗?它是否提到了有关 \NODEFAULTLIB 的任何内容?

You can check that all your projects and files are using the same Common run time library (Properties | C\C++) and check the Runtime Library setting. Including both the Multi-Thread debug DLL (\MDd) CRT and Multi-Threaded DLL(\MD) or other such mix up with the CRT libraries could cause something like this.

Can you post the linker output? does it mention anything about \NODEFAULTLIB?

九八野马 2024-10-15 20:34:58

您可以使用预处理到文件选项。这将很快告诉您该函数来自哪里!

也许您正在使用它们的 _tcs 版本?

you can use the preprocess-to-file option. This will tell you quickly where the function come from !

May be you're using the _tcs-versions of them ?

甜柠檬 2024-10-15 20:34:58

这通常是由于链接使用不同选项或不同运行时库生成的对象引起的。我猜你的一些对象是在启用调试选项的情况下编译的,而其他对象则没有或类似的东西。

This is usually caused by linking objects that were generated using either different options or different runtime libraries. I would guess that some of your objects were compiled with debugging options enabled and others were not or something similar.

咋地 2024-10-15 20:34:58

因为它们是自动包含在vs2010的CRT运行时链接中的。

如果您尝试导出包含这些内容的函数,也许可以在它们前面加上 c_

Because they are automatically included in the CRT runtime vs2010 links to.

If you try to export function that wrap around these stuff, maybe prefix them with a c_ ?

忘东忘西忘不掉你 2024-10-15 20:34:58

@sirjorj--
swprintf 在 wchar.h 中定义。您#include 了哪些标头?

@sirjorj--
swprintf is defined in wchar.h. What headers are you #including?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文