function not a member of std::tr1

[Marvin]

I am trying to move my project from a Win11 pc to a new Win11 pc. I am using the Embarcadero C++ Builder 12 compiler. Project works fine on old pc but when I try to compiler it on new pc I get the error
function not a member of std::tr1
I am using the the same OWLNext libraries, same code, and same compiler on both PCs.
Any help would be greatly appreciated.

Marvin

[Vidar Hasfjord]

https://sourceforge.net/p/owlnext/wiki/Installing_OWLNext/#h-prepare-your-build-tools

[Marvin]

I am using OWLNext 6.44. I ran OWLMaker and built all the libraries -- no problems. But I am still getting      function not a member of std::tr1error. It originates from the transfer.h file in OWL.
What can I do??

Marvin

---

marvin_avery@yahoo.com

On Sunday, July 5, 2026 at 01:32:46 p.m. EDT, Vidar Hasfjord <vattila@users.sourceforge.net> wrote:

https://sourceforge.net/p/owlnext/wiki/Installing_OWLNext/#h-prepare-your-build-tools

function not a member of std::tr1

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/owlnext/discussion/97175/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[Ognyan Chernokozhev]

Hi,

Can you try to build the Classes example in 6.44? It also uses transfer.h

Are you using Clang or classic C++ compiler?

Jogy

[Vidar Hasfjord]

See: FAQ | How do I resolve errors referring to "boost" or "std::tr1"?

PS. Documentation improvement suggestion: In Installing OWLNext | Set up your IDE, add something about proper Boost configuration for Embarcadero product users. Currently, only OWLROOT is mentioned in the configuration of the include paths. In addition, Boost must be installed (using the package manager) and CG_BOOST_ROOT (and in particular "$(CG_BOOST_ROOT)\boost\tr1\tr1") must be included.

[Marvin]

I use both the classic and clang compilers. Can I install both versions of Boost and simply include the appropriate version for each compiler?

[Ognyan Chernokozhev]

On my machine I have installed for C++ Builder 12:

• Boost 1.39 for the Win32 Classic Toolchain
• Boost 1.70 for the Win32 Clang-enhanced Toolchain
• Boost 1.85 for the Win64x Toolchain

They should have no problem coexisting.

[Marvin]

I have been very busy and it took me awhile to do this.....
I got fed up and completely re-installed Builder 12. I have 2 versions of my application -- a "regular" version and a debug version. Code is the same, I just use different compiler switches.

Lo and behold, when I used the clang version the "regular" version compiled, linked and ran perfectly! When I compiler the debug version, I got the same error as before. But, when I switched it to the clang compiler, It compiled perfectly but I now got a linking error:
Unable to open file 'OWL-6.44-C770-X86-DS.LIB

On my old win11 PC, this library was never used. In addition, when I run OWLMaker, this library does not get created.

Any idea as to what is happening?

Also, I only installed Boost 1.39. So why is the Clang-enhanced Toolchain working with the Clang compiler?

Marvin

[Ognyan Chernokozhev]

Unable to open file 'OWL-6.44-C770-X86-DS.LIB

On my old win11 PC, this library was never used. In addition, when I run OWLMaker, this library does not get created.

That would be clang 32-bit debug single-threaded library (see OWLNext Library Files Naming Convention)

Have you selected these options when building OWLNext 6.44 with the Clang compiler?

I have selected all and I have it in my build environment.

Also, is this the library that you really want to use? You may for example expect to use the multi-threaded version, but may not have the correct settings for the debug configuration.

[Vidar Hasfjord]

@marvinavery wrote:

Also, I only installed Boost 1.39. So why is the Clang-enhanced Toolchain working with the Clang compiler?

This is just a guess, but presumably the Clang toolchain's standard library headers do have support for TR1, so there is no need for Boost, maybe? So I guess Boost is only required for the classic BCC32 toolchain.

Note that nowhere does OWLNext explicitly include any Boost headers; only standard headers are included (which Boost provides for added TR1 functionality, if you include the "$(CG_BOOST_ROOT)\boost\tr1\tr1" path before the standard library header path).

PS. By the way, here is how the include paths are set for the classic BCC32 toolchain in "bc.mak (sourceforge.net)" in OWLNext 6.44:

INCDIR = $(INCDIR);"$(BCROOT)\include\windows\crtl";"$(BCROOT)\include\windows\sdk"
INCDIR = $(INCDIR);"$(CG_BOOST_ROOT)\boost\tr1\tr1\bcc32";"$(CG_BOOST_ROOT)\boost\tr1\tr1";"$(CG_BOOST_ROOT)"
INCDIR = $(INCDIR);"$(BCROOT)\include\dinkumware";"$(BCROOT)\include"

Note that the TR1 include paths come before the include paths to the Dinkumware standard library implementation.

[Marvin]

What options do I have to set to get the OWLmake wizard to generate the OWL-6.44-C770-X86-DS.LIB library?

[Vidar Hasfjord]

@marvinavery wrote:

What options do I have to set to get [OWLMaker] to generate the OWL-6.44-C770-X86-DS.LIB library?

I don't have any Embarcadero toolsets installed, so I cannot test this, but looking at the source code (OWLMaker/Toolset.h), it doesn't look like OWLMaker supports single-threaded runtime libraries for the Clang toolsets (flag fHasSingleThreadedLibs is only set for the classic toolsets).

As Ognyan suggests, switch your project settings to use the multi-threaded version of the runtime libraries. Then the linker will look for "owl-6.44-c770-x86-dt.lib" instead, which can be built by OWLMaker.

[Marvin]

Where is the flag fHasSingleThreadedLibs ?

[Vidar Hasfjord]

@marvinavery wrote:

Where is the flag fHasSingleThreadedLibs?

It is internal to the OWLMaker implementation (see source code I linked to). If this flag is not set, then OWLMaker will not display single-threaded libraries as an option on "Page 3: Select modules and build modes", which means it cannot build the single-threaded library.

Usually, there is no need to use the single-threaded library option in your project settings, and you should generally use the multi-threaded library option instead. Note that Microsoft stopped supporting single-threaded runtime libraries in their toolsets years ago.

[Marvin]

I was actually asking where the fHasSingleThreadedLibs flag is located in the Embarcadero C++ Builder IDE.

[Vidar Hasfjord]

@marvinavery wrote:

I was actually asking where the fHasSingleThreadedLibs flag is located in the Embarcadero C++ Builder IDE.

If you're asking where to find the option inside the IDE to select the multi-threaded RTL, I cannot help you, since I'm not an Embarcadero user, and neither a quick search on the net, nor a simple AI prompt, can give me an answer.

But, obviously, you've set it before, since according to your earlier post, your "regular" version "linked and ran perfectly" with the Clang toolset (which means it is likely linking "owl-6.44-c770-x86-t.lib", the release variant using the multi-threaded RTL).

What I can tell you is that, according to the Embarcadero documentation, the equivalent compiler option is -tWM. See "Multithread Programs".

In the ".cbproj" project file format used by the IDE, it is controlled by the <Multithreaded> element. E.g. in "6.44/source/owlcore/CBXE3/owl.cbproj (sourceforge.net)" used by OWLMaker:

<Multithreaded>true</Multithreaded>

If the option is set, the compiler will predefine the symbol __MT__, which is what the OWLNext source code (include/owl/private/owllink.h) looks for to determine the name of the OWLNext library to link. See Embarcadero documentation, "Predefined Macros".

[Ognyan Chernokozhev]

Ok, I was wrong when I said I have the file OWL-6.44-C770-X86-DS.LIB, what I was looking at was OWL-6.44-B770-X86-DS.LIB, which is built with the classic compiler. The Clang compiler does not have single-threaded option.

I cannot find any setting in C++ Builder 12 UI to switch to single-threaded model either.

For a quick check to see if multi-threading is enabled correctly in your project, you can put at the top of a source file code like this:

#if defined(__MT__)
#error MT enabled
#endif

and if the compilation fails, then you have it enabled correctly.

[Vidar Hasfjord]

@jogybl wrote:

For a quick check to see if multi-threading is enabled correctly in your project [...]

Proposal: It would be helpful if a similar check was made in OWLNext itself, so that a better error message is given when use of the single-threaded RTL is attempted with the Clang toolsets. Put it on the TODO list for the next maintenance update, maybe?

[Ognyan Chernokozhev]

Good idea. I added [feature-requests#281] for this.

[Vidar Hasfjord]

Here is Copilot's summary of the useful info in this discussion so far, which you can review and consider for updating our FAQ/documentation.

---

✅ 1. Expanded FAQ Entry: Boost/TR1 Support (Classic vs. Clang Toolsets)

The classic BCC32 compiler uses an older Dinkumware‑based standard library that does not provide full TR1 support. To compensate, Embarcadero historically shipped TR1 headers via Boost, and OWLNext’s classic build system ("bc.mak") expects these Boost TR1 headers to be present.

The modern Clang‑enhanced toolsets use libc++, which already includes modern equivalents of TR1 functionality. Therefore, the Clang toolsets do not require Boost/TR1.

Correct include‑path order for BCC32

OWLNext’s "bc.mak" shows the authoritative include‑path order needed for TR1 support:

$(BCROOT)\include\windows\crtl
$(BCROOT)\include\windows\sdk
$(CG_BOOST_ROOT)\boost\tr1\tr1\bcc32
$(CG_BOOST_ROOT)\boost\tr1\tr1
$(CG_BOOST_ROOT)
$(BCROOT)\include\dinkumware
$(BCROOT)\include

The important detail is that Boost TR1 paths must appear before the Dinkumware standard library paths. If Boost TR1 is missing or ordered incorrectly, BCC32 will emit errors such as “function not a member of std::tr1”.

Environment variable

OWLNext’s build system uses the environment variable CG_BOOST_ROOT to locate Boost. This must be set correctly for BCC32 builds.

Summary

• Boost/TR1 is required for the classic BCC32 toolset (correct path order essential).
• Boost/TR1 isnot required for the Clang toolsets.
• OWLNext 6.44 builds successfully with classic toolset when Boost/TR1 is configured as above.
  
  

---

✅ 2. New FAQ Entry: Link Errors When Using Single‑Threaded RTL with Clang Toolsets

The Clang‑enhanced toolsets in Embarcadero RAD Studio/C++Builder can compile projects using either single‑threaded or multi‑threaded RTL. However, OWLMaker intentionally does not build single‑threaded OWLNext libraries for Clang.

This is a design choice in OWLMaker:

• Single‑threaded RTL is obsolete and rarely used.
• Mixing ST RTL with MT libraries can cause subtle runtime issues.
• Clang toolsets are modern and intended for multi‑threaded usage.
  
  

What happens if your Clang project uses single‑threaded RTL?

The compiler will successfully compile your project, but the linker will fail.

This is because OWLNext’s library naming logic (in "include/owl/private/owllink.h") selects the library variant based on the __MT__ macro, predefined by the compiler.

Since OWLMaker does not build single-threaded variants with the Clang toolsets, the linker will emit an error such as “Unable to open file OWL-6.44-C770-X86-DS.lib”.

How to fix the link error

Switch your project to use the multi‑threaded RTL.

In the ".cbproj" file, this corresponds to:

<Multithreaded>true</Multithreaded>

The corresponding compiler option is -tWM.

Enabling multi‑threaded RTL causes the compiler to predefine __MT__, and OWLNext will link the correct Clang library variant (e.g. "OWL-6.44-C770-X86-DT.lib").

Summary

• Clang can compile ST RTL, but OWLMaker does not build ST OWLNext libraries.
• Linking fails because the expected single-threaded library variant does not exist.
• Use multi‑threaded RTL to link successfully.

[Marvin]

You suggested to edit the .cbproj file to change the <multithreaded> value to true.</multithreaded>

IT WORKED!!!!!!!

Thank you, thank you, thank you!

Marvin

[Vidar Hasfjord]

@marvinavery wrote:

[Setting the "multithreaded" element value] WORKED!!!!!!! Thank you, thank you, thank you!

Good to hear!

Any help would be greatly appreciated.

If you want to contribute something back, I'm sure our documentation about the issues you faced in this discussion can be much improved, by just including our findings (see my earlier posts). A few simple edits could save other Embarcadero users from similar headaches.

Perhaps our resident Embarcadero user and project administrator @sebas_ledesma would be able to review/help as well.

It is very easy to make simple edits to our wiki — just ask Ognyan to be added to the list of developers.

[Sebastian Ledesma]

I've updated to C++Builder 13.1 a couple of weeks ago. I will do a comprehensive test in a few days.
Also I've updated my subscription, so I will be able to support C++/ARM/Windows with OWLNext when the new compiler will be available.