I have the following generic function:
template <typename U>
auto CastVkArray(std::vector<U> &unique_handles)
{
std::vector<typename U::element_type> handles;
for(auto &u_handle : unique_handles) handles.push_back(*u_handle);
return handles;
}
The problem is/was that although I thought I instructed premake5 to use the version under a local directory in my project, it was using the system's installed version instead. The version mismatch meant that I was using an old vulkan.hpp header rather than the one I need.
Which I am temporarily using to convert unique handle arrays to non unique arrays. This code compiles just fine on my desktop (arch linux), however on my laptop (ubuntu) I get the error:
error: no type named ‘element_type’ in ‘class vk::UniqueHandle<vk::CommandBuffer>’
std::vector<typename U::element_type> handles;
I use premake 5 to generate my build environment and the script hasn't changed between the 2 systems. I checked that all the libraries I am using are the same version, in particualr, I made sure that the vulkan sdk is the same between the 2 computers.
I deleted and rebuilt my code multiple times to test for potential race conditions in compilation (just to see if anything changed), the error is always the same.
The one difference that I have found is that the reported version of premake in arch is 5.0.0-dev but on ubuntu it is 5.0.0-alpha14
But I have not been able to find the dev version on the official github repository of premake.
Related
As the title suggests, I cannot use variants such as llvm, cuda and the auto-differentiable variants with mitsuba 3.
I have checked that they are indeed variants using mitsuba.variants() as well as making sure they are listed in the config file, but when I try to run in jupyter notebook, I get the error that the LLVM dll cannot be found. scalar_rgb and scalar_spectral both work fine.
I built mitsuba directly from the repository, and so it should have included all the necessary dlls.
and below shows the enabled variants in the config file.
Background
I need to run a binary in an arm based computer(Jetson Nano) and i was compiling and running it without any problems until my team decided to use Generated Columns in sqlite3 a feature that was implemented in version 3.31.0 but the Ubuntu Image ran by said computer has a previous dev-version and results in the following crash using Dieselrs library
thread 'main' panicked at 'called `Result::unwrap()` on an
`Err` value: DatabaseError(__Unknown, "malformed database schema
(group) - near \"as\": syntax error")', src/common_queries.rs:182:35
(we handle the unwrap but i removed it in order to see the real message)
I know its a version problem since the message shown is similar to what its stated in the sqlite3 documentation
.... If an earlier version of SQLite attempts to read a
database file that contains a generated column in its schema,
then that earlier version will perceive the generated column syntax
as an error and will report that the database schema is corrupt.
and because in an x86 computer with sqlite3 version 3.34 works without a problem.
What has been tried
update libraries
I already tried downloading version 3.36 of SQLite from the official webpage and ran sudo make install but that didn't create the library in /usr/include but somehow it still compiles it and it still shows the same error. (maybe it knows where the new library is but its weird that despite that it still doesn't work).
Change db-schema
the simplest solution that i could come up with was to change the schema and store the generated column as a new column that would be generated with an after update trigger but that would mean that the database would no longer be in a Normal form.
Cross compilation
Since it works in an x86 machine I tried targeting the architecture, following different approaches that resulted in the following message
linking with `aarch64-linux-gnu-ld` failed: exit status: 1
....
....
....
aarch64-linux-gnu-ld: cannot find -lsqlite3
aarch64-linux-gnu-ld: cannot find -lgcc_s
which i guess comes from the fact that neither of them show up in /usr/aarch64-linux-gnu/include/ but installing libsqlite3-dev doesn't fix the issue.
Any ideas on how to fix this problem?
Try adding libsqlite3-sys = { version = "0.22.0", features = ["bundled"]} to your Cargo.toml. This forces libsqlite3 to be build from source for the correct target. This uses the latest version of sqlite.
See the documentation of libsqlite3-sys for details.
I am trying to build a custom modified version of the
MicroSIP softphone.
Before any modifications, I can't build the version 3.19.18 using VisualStudio 2017.
I am able to compile successfully the previous minor version: 3.18.5
The error is:
1>c:\users\xxxxxxxxx\microsip\maindlg.cpp(1038): error C2065: 'PJRPID_ACTIVITY_ON_THE_PHONE': undeclared identifier
If I look at the code that uses that identifier I come across this, that is new in 3.19:
case PJSUA_BUDDY_STATUS_ONLINE:
if (buddy_info.rpid.activity == PJRPID_ACTIVITY_ON_THE_PHONE) {
image = MSIP_CONTACT_ICON_ON_THE_PHONE;
if (PjToStr(&buddy_info.status_text).Left(4) == _T("Ring")) {
ringing = true;
If I look at the type of "buddy_info.rpid.activity" it's of type "pjrpid_activity" That is defined in "rpid.h" from the SIP library "pjsip" :
typedef enum pjrpid_activity
{
/** Activity is unknown. The activity would then be conceived
* in the "note" field.
*/
PJRPID_ACTIVITY_UNKNOWN,
/** The person is away */
PJRPID_ACTIVITY_AWAY,
/** The person is busy */
PJRPID_ACTIVITY_BUSY
} pjrpid_activity;
No 'PJRPID_ACTIVITY_ON_THE_PHONE' defined here. And that string can't be found anywhere else on that project.
This enum is part of the Open Source project pjsip which is currently on version 2.9.
I tried to look back into earlier versions to find out if that enum evolved and had the correct elements. No luck.
It looks like they are using a modified version of the pjsip library, but I can't find a link, a mention or anything that would help me to find out what is that missing dependency.
More than that, MicroSIP.org will charge you $95 to obtain a customized version including "source code and assistance with compilation if needed".
Of course it is needed if they keep secret the dependencies.
Anyway, MicroSIP is statically linked to the unknown pjsip library variant.
Microsip and PJSIP are both licensed under the GPLv2.
My question is: How to find out my missing dependency?
Are they required to disclose that information?
Does anyone know about a fork of pjsip that would be the one I am looking for?
Better, Has anyone been able to somehow compile MicroSIP, ver >= 3.19.0?
To build any distribution of Microsip, you should build pjsip first. Therefore you should set some source and library paths for the Microsip project. Then you can build cleanly. It may be that some library is missing like opus, etc... and you may need to find the current version of these and build them beforehand as well.
I came to see that you must be having different platform toolset for MicroSIP and PjProject. Try to build it from starting using the same build tool and platform toolset for the both of your project, it will automatically clear several issues.
I am trying to modify the behaviour of the DNS lookup functions in Linux for my project by setting it to write a random string in a file as a test.
Linux use some DNS resolver functions, mainly gethostbyname. Looking forward, I found out that the resolver functions are within the glibc6 library. So, I downloaded it, compiled, generating the libresolv.so, libnss_dns.so dynamic libraries. Then, I replaced the existing ones on my system, at /usr/lib/x86_64-linux-gnu/.
Note: I found out these libraries are the ones that resolves queries by modifying gethostbyname code and compiling again. Then, I saw which dynamic libraries changed.
By creating a program that uses res_query directly (a resolver function) and compiling with -lresolv, it works (I used ldd command and it uses the resolver library I created). But, using gethostbyname directly from the code, using wget or browsing the web I can't get it right.
What am I doing wrong?
I discovered what should I do:
Firstly, the function called isn't gethostbyname. It is _nss_dns_gethostbyname3_r, defined in resolv/nss_dns/dns-host.c. Looking at the source I realized that this function called another one to resolve DNS names, __libc_res_nsearch, defined in resolv/res-query.c. So this is the function! I added some file writting commands there and it worked like a charm. I called it from C code using gethostbyname, used wget and Firefox, all worked. When you compile the code you should replace the libresolv.so of your system by the new one.
Note: my glibc version is 2.19.
I hope this helps someone.
I am trying to build an old version of an application which consists of VC++ projects that were written in Visual Studio 2003.
My OS is Windows 7 Enterprise (64-bit).
When I try and build the solution I get the following errors:
error C4772: #import referenced a type from a missing type library; '__missing_type__' used as a placeholder
fatal error C1084: Cannot read type library file: 'Smegui.tlb': Error loading type library/DLL.
They both complain about the following import statement:
#import "Smegui.tlb" no_implementation
This is not a case of the file path being incorrect as renaming the Smegui.tlb file causes the compiler to throw another error saying it cannot find the library.
Smegui is from another application that this one depends on. I thought perhaps I was missing a dll but there is no such thing as Smegui.dll.
All I know about .tlb files is that they are a type library and you can create them from an assembly using tlbexp.exe or regasm.exe (the later also registers the assembly with COM)
There is also an Apache Ant build script which uses a custom task to invoke devenv.com to build the projects. This is the same script that the build server originally used to build the application. It gives me the same errors when I try and run it.
The strangest thing about this is that I knew it ought to work seeing as it is all freshly checked out from subversion. I tried many different combinations of admin vs user elevation, VS vs Ant build, cleaning, release.
I have got it to build successfully about 5 times but the build seems to be non-deterministic.
If anyone can shed some light on how this tlb stuff even works or what this error might mean I would greatly appreciate it.
I found a far more reliable solution: open the tlb with oleview.exe and then close it.
Not sure what this actually does but it works every time.
I think oleview is actually one of the samples included with Visual Studio but I haven't had the time to debug it and see what it is doing.
I ran into this error because one type library was trying to load a dependent type library, which it could not find. Even though the dependent type library was in the same directory, and even though that directory was in the searchable path, the compiler would error loading the first type library, but not mention the dependent type library in the error.
To find the pseudo-missing type library, I ran Process Monitor (procman64.exe) during the compile. This showed that after the reported type library had successfully loaded, a dependent type library could not be found. It even showed all of the places that it was looking for the dependent type library, none of which were where it should have been looking (e.g.: ).
The fix was to add a <PreBuildEvent> to the project to copy the dependent .tlb file to one of the directories that was actually being searched.
<PreBuildEvent>
<Command>copy /Y ..\Lib\Interop\CWSpeechRecLib.tlb .\</Command>
</PreBuildEvent>
http://msdn.microsoft.com/en-us/library/sce74ah7%28VS.71%29.aspx
smegui.tlb is referencing some other tlb that the compiler can't find. If you have the .idl for smegui you might be able to figure out what the other is. I suspect the missing tlb is something that original build machine had registered but that your machine doesn't have registered.
A type library is a binary description of a set of interfaces, coclasses and enums. They're usually generated for COM components, in the case of tlbexp and regasm the tlb is created from the assembly metadata. For native COM components they are usually generated from an idl (Interface Description Language) file by the midl tool.
Edit:
I just noticed you're on x64 Windows. Are you building the project with a new version of Visual Studio? If so, are you targeting x86 or x64? If the latter, it may simply be a 32bit component that the compiler can't find (or less likely, a x64 component the x86 compiler can't find if you are targeting x86), for WOW64 the registry is virtualized for x86 vs. x64 applications.
Well I finally found out why I managed to get it to build sometimes and not others... sort of.
So long as I ran the build script with elevated administrator permissions and let that get as far as it could until that error occurred, then run the build script again as a protected administrator succeeded. Those steps must be done in that exact order with no other steps in between. If I try build in Visual Studio it does not work (although I did get it to succeed once). Probably some kind of virtualisation issue although it still doesn't quite make sense.
Well I don't need help on this any more and I know it's probably impossible to fully answer this question without knowing exactly what the build is doing. However if anyone does have any more thoughts I would happily receive them.
Cheers,
Steiny