Ошибка unresolved external builder c

Unresolved external

The unresolved external in your case, seems to be because the compiler is unable to find the path to the package data. You should find out if:

• The path exists in the compiler search path list.
• The package exists in the default package directory.

If one of them is true then the path isn’t the problem. However as Riho also mentions this is the most likely cause for the problem. The Embarcadero documentation wiki states the following about the unresolved external error:

The named symbol is referenced in the given module but is not defined anywhere in the set of object files and libraries included in the link. Check to make sure the symbol is spelled correctly.

You will usually see this error from the linker for C or C++ symbols if any of the following occur:

• You did not properly match a symbol’s declarations of __pascal and __cdecl types in different source files.
• You have omitted the name of an object file your program needs. You need to manually add all required packages to the Requires list.
• You did not link in the emulation library.

If you are linking C++ code with C modules, you might have forgotten to wrap C external declarations in extern “C”.

You could also have a case mismatch between two symbols.

Source: Unresolved external ‘symbol’ referenced from ‘module’.

Since it seems from the — although altered class names — it is not the case of a misspelling. You also state that you have added the package to the requires list so we rule out this as well. Since you are not linking to C modules we can omit that part as well. So it points to problems with the directory.

About the other questions

Your questions are all really interesting and many of the questions are questions I my self has been looking for answers for when I started developing packages and components for C++ Builder.

Are packages reliable using C++?

Packages are a fine solution to use for C++ Builder, Both C++ Builder is built to support packages and the Pascal written VCL framework. This means that certain implementations are different in C++ Builder than other compilers. This is a necessity to keep the language compatible with its Delphi sibling. For this reason you can use packages in C++ Builder almost as easily as if using Delphi.

Is linking to the first package by adding a reference to its BPI correct?

To start with the second part of your question here, using a lib file makes your package larger simply because it is using static linking — so your guess is correct. Now back to the first part of the question, linking to a package is fine by adding a reference to its BPI. But you do need to make sure that the path variable has been set correctly as Riho suggests in his answer.

Personally I always make sure to my packages to the proper directories in your users folder, the location of this is depending on your Delphi version and operating system version. As far as I recall it is under the Document and Settingsall usersshared documentsRad studio(version number)Packages but I could be mistaken about that.

Can we use the PACKAGE directive only on TObject-derived classes?

The PACKAGE macro is resolved into __declspec(package), you can compare it to __declspec(dllexport). The difference between these is that package is used when declared in a package, and dllexport is used when declared in a DLL. There is a topic about this on the official embarcadero forums titled __declspec(package) vs __declspec(dllexport). The author of the original post, also asks your exact question about this, but unfortunately that part of the question is unanswered.

I have a theory however, and I must emphasize that it is nothing more than a theory. Remy Lebeau writes as a response to the question in the forum post:

__declspec(dllexport) can be used for plain functions, data variables, and
non-VCL classes, and can be used in plain DLLs. __declspec(package) is
used for VCL components, and can only be used with packages.

So from reading his response it seems to me that package is simply exporting the class, just like dllexport does. And since dllexport as far as I can read from his response is to be used in plain DLLs only you have to use the package for exporting (even) non VCL classes from a package.

What is interesting about all this, is that a package is essentially a DLL as far as I recall, but I must admit I can’t find or remember the source of that information so take with a grain of salt.

Is splitting code into packages the best way to achieve the goal of isolating code?

Packages have some very prominent strengths when creating reusable components for the VCL. Obviously using packages limits the user to use either C++Builder or Delphi, but for components written to take advantage of the VCL framework it’s an excellent choice. Properly written packages can ease the reusability of components, and I believe it is the preferred method of distributing components for the VCL.

However if your code does not take advantage of the VCL framework in any way, I would consider using an ordinary library, either static or dynamic, simply to create a more cross compiler friendly approach.

Whether there are any better approach to isolating your code, really depends on the project you are working on. I like to keep code that communicates through use of VCL classes in packages, but code that does not require use of any VCL classes in regular libraries. Keep in mind though that you can easily use VCL classes in a DLL but you need to handle special cases if you choose to export functions with VCL String classes as parameters or return values.

Any general words of advice?

I’m not the most experienced developer of packages myself, but I have found that disabling runtime linking often solves a lot of my problems, while it is somewhat trivial to fix any problems for your own code, you can often run into 3rd party components that have trouble dealing with this. Having said that, I’m not a fan of distributing my packages along with my application as is required in this case. But to be honest that is a matter of taste.

Personally I found it difficult to find some proper answers to many of my questions, when I started creating components and packages. The official helpfile is not the most informative on the matter, but looking through the VCL source code, will often give you the best answer to your question. Besides there is a few other websites that can provide help, many of the sites are targeting Delphi though, but this you have to get used to though.

Delphi Wikia has some good articles about creating components, in particular Creating Components and Creating Packages There is also BCB Journal which is one of the few C++ Builder specific sites, it has some fine articles and an acceptable forum. The Delphi pages at About.com is also a good source of information, I’ve found lots of good hints and nice to knows there, in particular: Creating Custom Delphi Components — Inside and Out.

Компоновщик C ++ Builder предупредит вас, когда вы смешиваете объектные файлы, связанные классическим и clang вместе, помогая вам избежать ошибок компоновщика или времени выполнения.

Сегодня, в 2020 году, мы рекомендуем использовать современные компиляторы Clang, особенно с той работой, которую мы проделали для Win64 (например, совершенно новый отладчик), и улучшениями RTL, чтобы упростить обновление с классической версии. Однако многие клиенты обновляются поэтапно: сначала с классического Win32 до Clang Win32, а затем добавление Win64. Фактически, мы часто прямо рекомендуем это как стратегию обновления, чтобы сначала перейти на Clang, а затем на Win64, в два этапа.

Однако при переходе от классических компиляторов к clang возникает общая проблема. Объектные файлы (библиотеки .obj и .lib), созданные классическим компилятором Win32 и компилятором Clang, не совместимы друг с другом на двоичном уровне. (И classic, и clang могут связываться с Delphi, но classic и clang не могут связываться друг с другом.) Если вы попытаетесь создать приложение, в котором некоторые части построены с помощью Clang, а некоторые — с классическим смешением, вы можете ожидать чего угодно от ошибок компоновщика. к нестабильности во время выполнения. Тем не менее, это легко сделать случайно, как при обновлении, так и при добавлении новой библиотеки или EXE в ваш проект.

В версии 10.3.3, и это было задокументировано в онлайн-справке, но в то время не было опубликовано в блогах, мы добавили новое предупреждение компоновщика, чтобы помочь вам обнаружить такие ситуации.

Прежде чем показать решение, давайте кратко рассмотрим, что может произойти, если в ваших сборках есть эта ошибка.

Проблемы при несовпадении компиляторов

В версии 10.3.3 и новее вы получите предупреждение компоновщика — см. Ниже — перед любым из следующих событий. Но если вы используете старую версию, до того, как мы добавили предупреждение, диагностирующее проблему, вы могли увидеть только следующие ошибки. Они появляются при связывании приложения.

Ошибки времени компоновки

Когда приложение, созданное с помощью цепочки инструментов Clang, связано с классической библиотекой, вы можете увидеть следующие ошибки:

Когда приложение, созданное с помощью классической цепочки инструментов, связано с библиотекой, созданной с помощью Clang, вы можете увидеть следующие ошибки:

Ошибки времени выполнения

В некоторых случаях вы можете вообще не увидеть ошибок компоновщика, и вы запустите свое приложение. Скорее всего, в какой-то момент ваше приложение выйдет из строя, и будет сложно понять, почему, потому что код выглядит нормально. На самом деле это будет из-за того, что два разных компилятора делают что-то по-разному — разная структура памяти, выравнивание, ожидания библиотеки времени выполнения, обработка исключений, всевозможные возможные различия.

Не рекомендуется иметь странные ошибки компоновщика или странное поведение во время выполнения. Поэтому мы добавили предупреждение, чтобы проверить эту ситуацию.

Диагностика: предупреждение о новом компоновщике

RAD Studio / C ++ Builder 10.3.3 и новее предупреждает вас о смешивании clang и classic при компоновке. (Если возникают ошибки компоновщика, подобные описанным выше, это предупреждение выдается перед ними, поэтому вы увидите предупреждение перед любыми ошибками из-за проблемы.)

В сообщении говорится: «Предупреждение: несоответствие компилятора». а затем сообщает, что он ожидал и что обнаружил:

Итак, как компоновщик проверяет смешанные объекты и как он узнает, чего ожидать?

В приведенной выше ошибке у меня есть приложение VCL, связывающееся в статической библиотеке. Приложение VCL создано с помощью Clang. Библиотека построена на классическом. Приложение clang ссылается на библиотеку с помощью:

⸺ see documentation on linking with #pragma comment vs #link.

Ошибиться в несовпадении компиляторов очень легко. Как вы можете видеть на скриншоте справа, вы не можете легко определить, какой компилятор Win32 используется. Это то, что мы могли бы улучшить, но сейчас в нем указана целевая платформа, а не компилятор.

Теперь наш компилятор передает в каждый объект запись (небольшой фрагмент данных), в которой говорится, с каким компилятором он был построен (например, Clang Win32). При компоновке компоновщику предоставляется набор объектных файлов и библиотек в порядке, указанном в команде. линия. Он смотрит на первый объект, с которым связывается, и отмечает, что ожидает, что все последующие объекты будут построены с тем же компилятором, что и этот первый. Для каждого объекта, с которым он связан (и учитывая библиотеку, которая представляет собой просто набор объектов для каждого объекта в библиотеке), он проверяет, был ли он построен с помощью ожидаемого компилятора.

В противном случае выдается указанное выше предупреждение, которое вы также можете увидеть на изображении справа. Вы можете видеть, что он перечисляет ошибочный объект и то, с чем он был построен, а также объясняет, почему он искал другой компилятор. Это предназначено, чтобы помочь вам диагностировать настройку сборки.

TLDR

Краткое резюме: объединение объектных файлов, созданных двумя компиляторами, в один двоичный файл — плохая идея. Компоновщик выдаст вам предупреждение, если вы это сделаете, и расскажет, что для чего построено, чтобы вы могли это исправить. Это устраняет проблемы компоновщика и проблемы со стабильностью приложения!

Дальнейшее чтение

Компоненты упаковки или библиотеки, написанные на классических и Clang компиляторах Win32 C ++ На
этой новой странице документации обсуждается предупреждение компоновщика, но также содержится немного больше информации. В нем рассматривается, как использовать clang или классические двоичные файлы, если вы разработчик приложений и создаете приложения с несколькими частями (возможно, связываясь с библиотекой C ++ с открытым исходным кодом, которую вы также создаете), а также есть еще один раздел для библиотеки разработчик (например, написание компонентов или библиотек и распространение их среди клиентов.)