Entry point could not be located in the dynamic link library - c++ - c++

I created a DLL project in visual c++, and I wanted to use the cpprestsdk/casablanca.
Then I created a RestWrapper.h header file:
#pragma once
namespace mycpprest
{
class RestWrapper
{
public:
static __declspec(dllexport) void TestApi();
};
}
And RestWrapper.cpp source file:
#include "stdafx.h"
#include "RestWrapper.h"
#include <cpprest/http_client.h>
#include <cpprest/filestream.h>
#include <cpprest/json.h>
using namespace utility;
using namespace web;
using namespace web::http;
using namespace web::http::client;
using namespace concurrency::streams;
namespace mycpprest
{
void RestWrapper::TestApi()
{
auto fileStream = std::make_shared<ostream>();
// Open stream to output file.
pplx::task<void> requestTask = fstream::open_ostream(U("results.html")).then([=](ostream outFile)
{
*fileStream = outFile;
// Create http_client to send the request.
http_client client(U("http://13.231.231.252:3000/api/individual_employment_setting/detail/172"));
// Build request URI and start the request.
//uri_builder builder(U("/search"));
//builder.append_query(U("q"), U("cpprestsdk github"));
return client.request(methods::GET);
})
// Handle response headers arriving.
.then([=](http_response response)
{
printf("Received response status code:%u\n", response.status_code());
// Write response body into the file.
// return response.body().read_to_end(fileStream->streambuf());
stringstreambuf buffer;
response.body().read_to_end(buffer).get();
//show content in console
printf("Response body: \n %s", buffer.collection().c_str());
//parse content into a JSON object:
//json::value jsonvalue = json::value::parse(buffer.collection());
return fileStream->print(buffer.collection()); //write to file anyway
})
// Close the file stream.
.then([=](size_t)
{
return fileStream->close();
});
// Wait for all the outstanding I/O to complete and handle any exceptions
try
{
requestTask.wait();
}
catch (const std::exception &e)
{
printf("Error exception:%s\n", e.what());
}
}
}
When I build it, It success built.
Then I created Windows Console Application in visual c++ to test the DLL project that I created.
I copy the MyCpprestDll.dll, MyCpprestDll.lib and RestWrapper.h from MycppestDll project into DllTest project.
Then in DllTest project properties, in the Linker->input->Additional Dependencies: I added MyCpprestDll.lib
And here the code of DllTest.cpp:
#include "stdafx.h"
#include "RestWrapper.h"
#include <iostream>
using namespace mycpprest;
int main()
{
RestWrapper::TestApi();
system("PAUSE");
return 0;
}
It has no compile error, but when running the error says:
The procedure entry point ?TestApi#RestWrapper#mycpprest##SAXXZ could not be located in the dynamic link library
I tried to search about the related issues but I don't know how to or what to set to my entry point in my dll project.

You need to use dllexport when building your DLL, but dllimport when you are including it into another project
This answer shows you have to use some macros and pre-processor definitions to make it work.

In your RestWrapper.h header file do something as shown below.
Note that you must use __declspec(dllimport) for the importing executable to access the DLL's public data symbols and objects.
Also, make sure you define the macro RestWrapper_EXPORTS in C/C++->Preprocessor->Preprocessor Definitions in your DLL project properties.
#ifdef RestWrapper_EXPORTS
#define RestWrapper_APIS __declspec(dllexport)
#else
#define RestWrapper_APIS __declspec(dllimport)
#endif
namespace mycpprest
{
// This class is exported from the RestWrapper.dll
class RestWrapper
{
public:
static RestWrapper_APIS void TestApi();
};
}
Rebuild your DLL project. No changes needed in your DllTest project, just compile your DllTest project using the updated RestWrapper.h and RestWrapper.lib file.

Related

Mutex is not supported when compiling with /clr or clr:pure (cpprestsdk aka casablanca)

I create a CLR project in visual c++ with 64 bit configuration, and try to use cpprestsdk aka casablanca 64bit.
But when I run the project, an error occured:
1>------ Build started: Project: Timestamp, Configuration: Debug x64 ------
1>MyForm.cpp
1>c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.13.26128\include\mutex(8): fatal error C1189: #error: <mutex> is not supported when compiling with /clr or /clr:pure.
1>Testapi.cpp
1>c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.13.26128\include\mutex(8): fatal error C1189: #error: <mutex> is not supported when compiling with /clr or /clr:pure.
1>Generating Code...
1>Done building project "Timestamp.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Other error:
E2093 a local lambda is not allowed in a member function of a managed class Timestamp c:\Users\Laptop-attendance\source\repos\Timestamp\Timestamp\Testapi.h 97
The IDE shows an error about '[' characters in the .then function like .then([=](http_response response), which if you pointed it out, it says "a local lambda is not allowed in a member function of a managed class"
If I try the cpprestsdk in a Windows Console Application of Visual c++ with 64 bit configuration, it works fine.
I'm using visual studio 2017.
Do you think cpprestsdk cannot be used in CLR project of vc++?
Thanks.
Here's my code, and the code about cpprestsdk I just got it from its tutorial:
#ifndef TESTAPI_H
#define TESTAPI_H
#pragma once
#include <cpprest/http_client.h>
#include <cpprest/filestream.h>
#include <cpprest/json.h>
namespace Timestamp {
using namespace System;
using namespace System::ComponentModel;
using namespace System::Collections;
using namespace System::Windows::Forms;
using namespace System::Data;
using namespace System::Drawing;
using namespace utility; // Common utilities like string conversions
using namespace web; // Common features like URIs.
using namespace web::http; // Common HTTP functionality
using namespace web::http::client; // HTTP client features
using namespace concurrency::streams; // Asynchronous streams
/// <summary>
/// Summary for Testapi
/// </summary>
public ref class Testapi : public System::Windows::Forms::Form
{
public:
Testapi(void)
{
InitializeComponent();
//
//TODO: Add the constructor code here
//
}
protected:
/// <summary>
/// Clean up any resources being used.
/// </summary>
~Testapi()
{
if (components)
{
delete components;
}
}
private:
/// <summary>
/// Required designer variable.
/// </summary>
System::ComponentModel::Container ^components;
#pragma region Windows Form Designer generated code
/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
void InitializeComponent(void)
{
this->SuspendLayout();
//
// Testapi
//
this->AutoScaleDimensions = System::Drawing::SizeF(6, 13);
this->AutoScaleMode = System::Windows::Forms::AutoScaleMode::Font;
this->ClientSize = System::Drawing::Size(284, 261);
this->Name = L"Testapi";
this->Text = L"Testapi";
this->Load += gcnew System::EventHandler(this, &Testapi::Testapi_Load);
this->ResumeLayout(false);
}
#pragma endregion
private: System::Void Testapi_Load(System::Object^ sender, System::EventArgs^ e) {
auto fileStream = std::make_shared<ostream>();
// Open stream to output file.
pplx::task<void> requestTask = fstream::open_ostream(U("results.html")).then([=](ostream outFile)
{
*fileStream = outFile;
// Create http_client to send the request.
http_client client(U("http://13.231.231.252:3000/api/individual_employment_setting/detail/172"));
// Build request URI and start the request.
//uri_builder builder(U("/search"));
//builder.append_query(U("q"), U("cpprestsdk github"));
return client.request(methods::GET);
})
// Handle response headers arriving.
.then([=](http_response response)
{
printf("Received response status code:%u\n", response.status_code());
// Write response body into the file.
// return response.body().read_to_end(fileStream->streambuf());
stringstreambuf buffer;
response.body().read_to_end(buffer).get();
//show content in console
printf("Response body: \n %s", buffer.collection().c_str());
//parse content into a JSON object:
//json::value jsonvalue = json::value::parse(buffer.collection());
return fileStream->print(buffer.collection()); //write to file anyway
})
// Close the file stream.
.then([=](size_t)
{
return fileStream->close();
});
// Wait for all the outstanding I/O to complete and handle any exceptions
try
{
requestTask.wait();
}
catch (const std::exception &e)
{
printf("Error exception:%s\n", e.what());
}
}
};
}
#endif /*TESTAPI_H*/
At the very end of this answer, Hans Passant gives a hint which is useful in your case. Basically, you need a separate c++ library (clr support turned off) where you wrap the cpprest code, link this library from your CLR project and be sure no included headers will bring <mutex> in.
Just an example, have a class like this, in a restwrapper.h header file:
class RestWrapper
{
public:
void test();
};
In its implementation file, restwrapper.cpp:
#include "restwrapper.h"
#include <cpprest/http_client.h>
#include <cpprest/filestream.h>
#include <cpprest/json.h>
using namespace utility; // Common utilities like string conversions
using namespace web; // Common features like URIs.
using namespace web::http; // Common HTTP functionality
using namespace web::http::client; // HTTP client features
using namespace concurrency::streams; // Asynchronous streams
void RestWrapper::test()
{
auto fileStream = std::make_shared<ostream>();
// Open stream to output file.
pplx::task<void> requestTask = fstream::open_ostream(U("results.html")).then([=](ostream outFile)
{
*fileStream = outFile;
// Create http_client to send the request.
http_client client(U("http://13.231.231.252:3000/api/individual_employment_setting/detail/172"));
//etc ...
}
You can compile this class in a DLL (linking cpprest and all its related libraries) then make your CLR project link that library. In the CLR project you need to include restwrapper.h only, which in turn includes nothing:
#include <restwrapper.h>
System::Void Testapi_Load(System::Object^ sender, System::EventArgs^ e)
{
RestWrapper wrapper;
wrapper.test();
}
You can call a class that uses mutexes from a CLR project, what you need to do is create a normal c++ project and create classes that have the required functionality but don't expose <mutex> in their headers, you are then free to call these classes from your CLR project.
Just right click your .cpp file, and under "General -> Common Language Runtime Support" select "No Common Language RunTime Support".
Simplest solution really.

Having trouble building and using a DLL in C++

Here is the error I am receiving when running the project that I am using the DLL in:
The odd thing is that this was working at one point. I took a break from this project for a while and now it is not working. Not much has changed besides changing a couple of the parameters.
My setup includes a project in which I build the DLL. This project is then used in a solution with another project that I use to test it. I followed this example: https://msdn.microsoft.com/en-us/library/ms235636.aspx in which I also followed the first time and had it working, now it has stopped.
After realizing it seems to be only one of the functions that is causing the problem I have removed all of the extra code, tried renaming the function, removing everything in it and it is STILL not working.
You can see the function definitions and signatures to see how I am attempting to get this to work below
I have also tried using the "SCOREINTERFACECPP" macro I created on the function instead of the class and I get the same error.
In the project I am testing it in I added the DLL project as a reference and a dependent project, then imported the header file. The other functions I have in the dll (that I have removed from this code for simplicity sake) seem to be working.
Header:
#ifdef SCOREINTERFACECPP_EXPORTS
#define SCOREINTERFACECPP __declspec(dllexport)
#else
#define SCOREINTERFACECPP __declspec(dllimport)
#endif
#include <time.h>
#include <queue>
namespace ScoreInterfaceCPP
{
class SCOREINTERFACECPP ScoreInterface
{
public:
ScoreInterface();
~ScoreInterface();
static void SubmitLogin(const std::string &displayName, const std::string &password);
static void Shutdown();
static SIEvent* GetNextEvent();
static void ClearEvents();
static int GetEventCount();
private:
static std::queue< SIEvent* > mSIEvents;
static bool mGameIsAuthorized;
static std::string mGameName;
static std::string hexedKey;
static std::wstring mAddress;
static void SubmitEventString(std::string eventString);
static int SubmitWithNewThread(void* data);
static void PostMessage(std::string data, std::string iv);
};
}
Source:
#include <sstream>
#include <SDL/SDL_thread.h>
#include <boost/tokenizer.hpp>
#include "ScoreInterfaceCPP.h"
#include "Network.h"
using namespace ScoreInterfaceCPP;
/*
ScoreInterfaceCPP.h
Handles the sending and receiving of events.
*/
ScoreInterface::ScoreInterface()
{
}
ScoreInterface::~ScoreInterface()
{
}
void ScoreInterface::SubmitLogin(const std::string &displayName, const std::string &password)
{
}
void ScoreInterface::SubmitEventString(std::string eventString)
{
}
int ScoreInterface::SubmitWithNewThread(void* data)
{
return 0;
}
SIEvent* ScoreInterface::GetNextEvent()
{
return NULL;
}
int ScoreInterface::GetEventCount()
{
return 0;
}
void ScoreInterface::ClearEvents()
{
}
void ScoreInterface::Shutdown()
{
}
Test file:
#include "ScoreInterfaceCPP.h"
using namespace ScoreInterfaceCPP;
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
ScoreInterface si = ScoreInterface();
si.SubmitLogin("noplayer", "nopassword");
return 0;
}
In my experience, usually problems of this type come with two things you should check (assuming the DLL was built successfully):
Check that the DLL being loaded at runtime is the correct version.
Ensure that the function in question is actually exported.
For the first issue, you can use a utility such as Process Explorer and look at the DLL handles that are loaded for your running exectuable. If you are using Visual C++, you can also look at the Output Window listing of the DLL's that are loaded, and ensure that the version you're using is being loaded.
Many times during development, you may have several (either by accident or by design) versions of your DLL lying in a directory that is accessible by Windows (see DLL Search Order), and thus an old or different version of your DLL is being loaded when you run your application.
For the second issue, there is dumpbin.exe, but I find the Dependency Walker a little more friendly to use. These utilities will show you the functions that are exported from the DLL.
If it is discovered that the function was not exported, then you need to rebuild your DLL, ensuring that __declspec(dllexport) has been used on the function or class you're exporting.

Use C++/CLI Library in C++ native code and how to link

I want to use some code that executes a http-post, and because I'm not too familiar with c++ and what libraries you can use, and I am probably too dumb to get libcurl and curlpp to work, I found a link explaining how to use the .net version.
Alright so I created a class. Header File:
public ref class Element
{
public:
Element();
virtual ~Element();
void ExecuteCommand();
};
Class file:
#include "Element.h"
Element::Element()
{
}
Element::~Element()
{
Console::WriteLine("deletion");
}
void Element::ExecuteCommand(){
HttpWebRequest^ request = dynamic_cast<HttpWebRequest^>(WebRequest::Create("http://www.google.com"));
request->MaximumAutomaticRedirections = 4;
request->MaximumResponseHeadersLength = 4;
request->Credentials = gcnew NetworkCredential("username", "password", "domain");
HttpWebResponse^ response = dynamic_cast<HttpWebResponse^>(request->GetResponse());
Console::WriteLine("Content length is {0}", response->ContentLength);
Console::WriteLine("Content type is {0}", response->ContentType);
// Get the stream associated with the response.
Stream^ receiveStream = response->GetResponseStream();
// Pipes the stream to a higher level stream reader with the required encoding format.
StreamReader^ readStream = gcnew StreamReader(receiveStream, Encoding::UTF8);
Console::WriteLine("Response stream received.");
Console::WriteLine(readStream->ReadToEnd());
response->Close();
readStream->Close();
}
If I set the configuration type of this project to Application (exe), and create a new .cpp file where I create an Instance of this Element it works fine.
But my question is: Is it possible to create a .dll/.lib Library from this project and use it in a C++ project without CLI? (I don't want to use ^ for pointers :( )
Even if it's not possible, I have another problem.
When I link the library in a C++/CLI project. I get
unresolved token (06000001) Element::.ctor
unresolved token (06000002) Element::~Element
unresolved token (06000003) Element::ExecuteCommand
3 unresolved externals
the code for main.cpp in the second project is just the following:
#include <Element.h>
int main(){
return 0;
}
Thank you
As Hans Passant already stated: you must compile your C++/CLI code as Dynamic Library in order to be able to consume it from an unmanaged application. CLI/Managed code cannot run from/cannot reside in static libraries.
If you change the C++/CLI library target from Static library to Dynamic library you'll be able to compile successfully your unmanaged C++ application.
One thought from my side:
I think you'll be better if you use mixed mode C++/CLI DLLs to consume the managed functionality - you'll be able to free your consumer application completely from referencing the CLR.
The Header of such mixed mode Wrapper for your Element class would look like this:
#pragma once
#pragma unmanaged
#if defined(LIB_EXPORT)
#define DECLSPEC_CLASS __declspec(dllexport)
#else
#define DECLSPEC_CLASS __declspec(dllimport)
#endif
class ElementWrapperPrivate;
class __declspec(dllexport) ElementWrapper
{
private:
ElementWrapperPrivate* helper;
public:
ElementWrapper();
~ElementWrapper();
public:
void ExecuteCommand();
};
And the implementation would look like this:
#include "ElementWrapper.h"
#pragma managed
#include "Element.h"
#include <msclr\auto_gcroot.h>
using namespace System::Runtime::InteropServices;
class ElementWrapperPrivate
{
public:
msclr::auto_gcroot<Element^> elementInst; // For Managed-to-Unmanaged marshalling
};
ElementWrapper::ElementWrapper()
{
helper = new ElementWrapperPrivate();
helper->elementInst = gcnew Element();
}
ElementWrapper::~ElementWrapper()
{
delete helper;
}
void ElementWrapper::ExecuteCommand()
{
helper->elementInst->ExecuteCommand();
}
Then just compile your Element.cpp + ElementWrapper.cpp to a DLL and use the ElementWrapper.h in your unmanaged applications.

How to include the two different versions of the same header?

I am writing file conversion code from a proprietary file format to one more generic. My goal is to support multiple versions of the manufacturer's file format.
I have a multiple versions of the same proprietary headers. The headers define various structs which comprise the main file header (the file is simply a large header followed by raw data).
I need to read the first 4 bytes of the source file to determine the file version. The file version, in turn, tells me which version of the C-structs was used to create the file.
The issues are:
I can't modify the proprietary headers
The headers do not use namespaces or classes
There are a good handful of macros defined in the headers
Possible solutions:
Build different converter binaries for each file version type :-(
Inconvenient for both user and developer
Dynamically load libraries for each version
The converter is plugin-oriented, so there's already a lot of this happening
I have tried hacking with namespaces:
namespace version1 {
#include "version1.h"
}
namespace version2 {
#include "version2.h"
}
int main (void) {
version1::header *hdr = new version1::header;
return 0;
}
But this won't work because of include guards, and because there are multiple macros are redefined in each header.
Is there an elegant way to handle this?
You could use two different source files, together with a forward declaration:
// Forward declare in main.cpp:
namespace version1
{
struct header;
}
namespace version2
{
struct header;
}
// version1.cpp:
namespace version1
{
#include <version1.h>
}
version1::header* new_v1_header()
{
return new version1::header;
}
// other functions using `version1::header`
// version2.cpp:
namespace version2
{
#include <version2.h>
}
version2::header* new_v2_header()
{
return new version2::header;
}
// other functions using `version2::header`
Another alternative is to implement a wrapper class, which has a base-class that is just an empty shell:
class header_base
{
virtual int func1(char *stuff) = 0;
... many other virtual functions.
};
// Create implementation of header_v1 or header_v2:
header_base* make_header(unsigned int magic);
header_base.cpp:
#include "header_v1.h"
#include "header_v2.h"
header_base* make_header(unsigned int magic)
{
switch(magic)
{
case Magic_V1:
return new header_v1;
case Magic_V2:
return new header_v2;
default:
assert(0);
return 0;
}
}
and then implement, in two separate
in headerv1.h:
class header_v1 : public header_base
{
int func1(char *stuff);
...
};
header_v1.cpp:
#include "header1.h"
int header_v1::func1(char *stuff)
{
...
return 17;
}
And similar for header_v2.h and header_v2.cpp.

How to log with pantheios to a file?

I tried the exemple from pantheios to log to a file but can't manage to make it work.
Messages are correctly displayed in the console but the log file isn't created.
I tried to change severity levels since I saw that thread, but no one works.
Here's the code :
/* Pantheios Header Files */
#include <pantheios/pantheios.hpp> // Pantheios C++ main header
#include <pantheios/inserters/args.hpp> // for pantheios::args
#include <pantheios/inserters/exception.hpp> // for pantheios::exception
#include <pantheios/backends/bec.file.h> // be.file header
/* Standard C/C++ Header Files */
#include <exception> // for std::exception
#include <new> // for std::bad_alloc
#include <string> // for std::string
#include <stdlib.h> // for exit codes
/* ////////////////////////////////////////////////////////////////////// */
/* Define the stock front-end process identity, so that it links when using
* fe.N, fe.simple, etc. */
PANTHEIOS_EXTERN_C const PAN_CHAR_T PANTHEIOS_FE_PROCESS_IDENTITY[] = PANTHEIOS_LITERAL_STRING("example.cpp.file");
/* ////////////////////////////////////////////////////////////////////// */
#define PSTR(x) PANTHEIOS_LITERAL_STRING(x)
/* ////////////////////////////////////////////////////////////////////// */
int main(int argc, char **argv)
{
try
{
#ifndef PANTHEIOS_USE_WIDE_STRINGS
pantheios::log_DEBUG("main(", pantheios::args(argc, argv), ")");
#else /* ? !PANTHEIOS_USE_WIDE_STRINGS */
STLSOFT_SUPPRESS_UNUSED(argc); STLSOFT_SUPPRESS_UNUSED(argv);
#endif /* !PANTHEIOS_USE_WIDE_STRINGS */
pantheios::log_NOTICE(PSTR("stmt 1"));
// Set the file name for the local back-end, truncating the
// file's existing contents, if any.
pantheios_be_file_setFilePath(PSTR("log.local"), PANTHEIOS_BE_FILE_F_TRUNCATE, PANTHEIOS_BE_FILE_F_TRUNCATE, PANTHEIOS_BEID_LOCAL);
pantheios::log_NOTICE(PSTR("stmt 2"));
// Set the file name for the remote back-end.
pantheios_be_file_setFilePath(PSTR("log.remote"), PANTHEIOS_BEID_REMOTE);
pantheios::log_NOTICE(PSTR("stmt 3"));
// Set the file name for all back-ends.
pantheios_be_file_setFilePath(PSTR("log.all"));
pantheios::log_NOTICE(PSTR("stmt 4"));
pantheios::log_DEBUG(PSTR("exiting main()"));
system("pause");
return EXIT_SUCCESS;
}
catch(std::bad_alloc&)
{
pantheios::log(pantheios::alert, PSTR("out of memory"));
}
catch(std::exception& x)
{
pantheios::log_CRITICAL(PSTR("Exception: "), pantheios::exception(x));
}
catch(...)
{
pantheios::logputs(pantheios::emergency, PSTR("Unexpected unknown error"));
}
return EXIT_FAILURE;
}
/* ///////////////////////////// end of file //////////////////////////// */
I have an "include_pantheios.cpp" file for implicit link purpose. Here it is :
/* Pantheios Header Files */
#include <pantheios/implicit_link/core.h>
#include <pantheios/implicit_link/fe.simple.h>
#include <platformstl/platformstl.h>
#include <pantheios/implicit_link/be.file.h>
#if ( defined(UNIX) || \
defined(unix))&& \
( defined(_WIN32) || \
defined(_WIN64))
# include <unixem/implicit_link.h>
#endif /* _WIN32 || _WIN64 */
Does somebody see where my problem come from?
Thanks in advance,
Vincent
I think part of your confusion comes from the example doing too much: it shows local and remote files all in one. A simpler example would be:
// Headers for main()
#include <pantheios/pantheios.hpp>
#include <pantheios/backends/bec.file.h>
// Headers for implicit linking
#include <pantheios/implicit_link/core.h>
#include <pantheios/implicit_link/fe.simple.h>
#include <pantheios/implicit_link/be.file.h>
int main() {
pantheios::log_NOTICE("log-1"); // save until log file set
pantheios_be_file_setFilePath("mylogfile"); // sets log file; write "log-1" stmt
pantheios::log_NOTICE("log-2"); // write "log-2" stmt
pantheios_be_file_setFilePath(NULL); // close "mylogfile"
pantheios::log_NOTICE("log-3"); // save until log file set
pantheios_be_file_setFilePath("mylogfile2"); // sets log file; write "log-3" stmt
pantheios::log_NOTICE("log-4"); // write "log-4" stmt
} // closes "mylogfile2" during program closedown
The problem with the original code, which I think comes from a Pantheios example program, is that it's trying to illustraet how to use local and remote back-ends at the same time as trying to illusteate how to use the be.file backend.
Forget all the different back-ends, and concentrate on the be.file-specific stuff.
HTH
I got the same problem, for future people, the problem is the order to link libraries
Pantheios Forum :
https://sourceforge.net/projects/pantheios/forums/forum/475314/topic/5313841/index/page/1
I just link the pantheios.1.be.file.gcc44 before the pantheios.1.be.fprintf.gcc44
I think the issue is the order in which you link, but I don't quite see how it's possible given the code you posted.
I encountered the same issue, and I realized that it was because I was linking two backends at once: file and fprintf. More specifically, it was because I was linking fprintf before file. When I switched the order to link file first, then it would create and use the log file, but would not output to stdout when I commented out pantheios_be_file_setFilePath. So apparently whichever is linked first is the only one that will work (look up multiple backends).
As far as I can tell this code is identical to the file stock back-end sample given with the library, so it ought to work.
How are you determining that the log files are not written? These are relative paths - try using absolute paths to be sure you are looking in the correct place.
If all else fails, you could debug through the code (after the filepath is set) to find out why nothing is getting written out.