Has anyone been successful getting Joomla running under IIS/Phalanger?
I have gone through the Phalanger 3.0 installation, followed the instructions on making Joomla a app that runs using the Phalanger compiler, but for some reason I get an error before the app even starts up:
Error: Class 'JLogEntry' not found in C:\inetpub\wwwroot\nfspv3\libraries\joomla\log\log.php on line 169, column 4.
I was running Joomla 2.5 on IIS/MySQL prior to installing Phalanger 3.0 so I am wondering if it's an issue with the Phalanger compiler not interpreting the PHP right? Would be good to know if anyone has Joomla working with Phalanger ok.
The error is telling you that the class JLogEntry hasn't been defined, yet it has been referenced by something the expects it to be defined. This means a dependency wasn't satisfied. Your log.php is dependant on a file that defines the JLogEntry class. The JLogEntry class is defined in entry.php according to this:
http://www.reference.joomlademo.de/nav.html?_classes/index.html
and this:
http://www.reference.joomlademo.de/nav.html?_classes/index.html
So for whatever reason you're not satisfying that dependency. If I was on your system I'd poke around for that file, check if it exists, is corrupt, correctly versioned, or otherwise prevented from being executed.
If you still suspect something is hinky with your Phalanger compiler then test it. Write a simple "hello world" and prove whether it works or not. Infact do it in the same file (after backing up the file) to prove whether it's executing. The compiler is working at some level or else it wouldn't be showing you error messages.
Edit:
According to #highcore the Phalanger 3.0 compiler fails to implement regular expressions in the way Joomla expects. Joomla relies on this to resolve the filenames it will include. Thus, entry.php is never included leaving JLogEntry undefined. The suggested work around is to avoid reg ex and split the file names.
Related
Whenever I install puppeteers in my netbeans project, A red Exclamation Mark appears on my project name which is actually representing error in 'install.js' (node Modules/puppeteers/install.js). How to resolve this?
Error
This error is shown as a return statement is normally only expected in functions (but actually also valid outside of them). Therefore, the netbeans syntax checker tells you that this is invalid code (although it is valid).
Most likely, you want Netbeans to ignore the node_modules folder, as bad code inside any of these modules should not be shown as an error in your project.
My program has a very specific error that took me a while to track down - now I don't know how to fix it. My code is very long and in many files and I don't see much point in posting it here.
In the IDE, everything runs fine, in both Debug and Release (with the runtime library set to either /MTd or /MT, respectively, so I'm assuming all dependencies are included).
However, when I run the standalone, I get a crash. At first I thought it was a dependency problem but it doesn't seem so.
At some point in the code, I am accessing a vector via a method call: t->GetList(), where GetList is defined as std::vector<T*> & GetList() and the method simply returns a member variable (simply defined as std::vector<T*> field in the class).
It turns out, if I print out the size of the list while running from the IDE, I get 0 (which is the correct answer in this case).
However, when doing the same thing running from standalone, I get the size as 467467353.
I tried changing the method declaration to std::vector<T*> * GetList() and doing return &field; and updating the rest of the code but this didn't fix anything.
I then tried replacing the member variable field with a pointer, and in the constructor instantiating a new vector and deleting it in the destructor. Still no luck.
So I made a simple test case program that simply made a class with a vector field, and a method to return a reference to it. Then in main I would create an instance variable and getting the vector and printing the size. This worked both in VC++ and as a standalone - both returned zero.
This is driving me nuts and I can't figure out why I'm getting different behaviour. Why is the standalone running differently, and what should I be looking at to fix this?
Thanks
Okay so it was literally a bug in my code that was very well hidden. I was dynamically casting to a wrong type.
Somehow it slipped past when I was running on Windows and OSX in both Debug and Release, and as a standalone on OSX. Good thing I found it.
I have a project that is running fine on Android and WinPhone 8. When I attempt to run on iOS, I've getting the following error
Microsoft.Practices.ServiceLocation.ActivationException: Cannot
register: No public constructor found in x
where x is whatever SimpleIoc.Default.Register<T, TU>(); the flow hits first. I've moved the code around (as suggested elsewhere) to ensure all of the platform specific SimpleIoc calls are made in ViewModelLocator.
I've added public default ctors in the classes that are complaining about the error (I have though set the PreferredConstructor to the original, not the newly added public ctor).
I have a feeling that this error is a false positive (something else is failing, but pointing at that code).
Using Xam.iOS via a build server (the code is coming from VS2015). Xcode is running the 8.3 emulators (it may need updating to allow for 8.4 testing)
It could be that the Linker is optimising away the constructor, if it thinks it's not used. Try setting the Linker Options to "Don't Link" and see if it does it again, or even new-up an instance of the class elsewhere so that the Linker knows that the constructor is used. You don't necessarily want to leave it that way, but if it eliminates the error, you'll at least know the reason.
The [Preserve] attribute did the trick for me.
Decorate constructor with it and keep your linker settings.
This attribute is part of the Microsoft.WindowsAzure.MobileServices namespace.
I'm having some real difficulties porting a really old Visual Studio 97 C++ project to Visual Studio 2010. Let me begin by first giving a little background on the errors I was getting immediately prior to this new LNK1224 error because they may be related, but I'm not sure.
Prior to my new error I was receiving this error:
error LNK2005: "void __cdecl operator delete(void *)" (??3#YAXPAX#Z) already defined in LIBCMT.lib(delete.obj) nafxcw.lib(afxmem.obj)
Through some digging I found that the reason for this error was because both the MFC and CRT libraries contain definitions for "new" and "delete" so they were colliding. Microsoft provides 2 solutions for this detailed in http://support.microsoft.com/kb/q148652/ . One of them was to make sure that in all your files you always include the MFC headers (afx stuff) first. Well there are about 100 files in this project and I just got tired of trying to find the files that were including resources in the wrong order. So I went with the other solution which is basically forcing libraries to load in a particular order. Basically you have to tell the compiler to ignore a particular library so that you can load it explicitly your self in the order that you choose. In my case, it was nafxcw.lib.
So under Project Properties --> Linker --> Input, I explicitly ignored nafxcw.lib and then explicitly included it at the front of the list.
So after doing this, my LNK2005 errors went away. But they were replaced with one single link error.
error LNK1224: invalid image base 0x287600000
I don't know if I fixed my previous link errors correctly and this new link error is in fact the next thing I have to deal with, or I simply created a more critical link error that is basically stopping the linking process before it gets to my original LNK2005 errors. In either case, there isn't much information I could find on this error. Microsoft doesn't say much in this link about it http://msdn.microsoft.com/en-us/library/3ya3f8wz%28v=vs.80%29.aspx
You specified an invalid base address for the image. Base addresses must be 64KB aligned (the last four hex digits must be zero) and image base must fit within a 32-bit signed or unsigned value.
This isn't all that helpful to me and there seems to be no other clues as to where this problem is coming from. I don't know what the next step is.
OK, so it looks like I have solved my own problem. Here is what I did. I needed to know where the heck this number was coming from so I simply used Notepad++ to do a word search through all the project files looking for "2876" which I got from the error message "LINK : fatal error LNK1224: invalid image base 0x287600000". I found that in the project file (.vcxproj) had the following entry in it:
<BaseAddress>0x287600000</BaseAddress>
So I opened it up and sat there wondering how this number was wrong. I mean I don't even know what this field is for. I didn't even generate this file, M$ made it. Why would the IDE create it's own input file incorrectly? Anyways, as I was trying to google this "BaseAddress" item to figure out what it was, it dawned on me that it looked like there were too many zero's. So I went back and counted and sure enough, this wasn't a 32-bit number, it was a 36-bit number. Deleted one of the zero's, recompiled, and boom it worked. Low and behold, that's kind of what the defintion I looked up, mentioned in the problem statement, hinted at looked up earlier on MSDN but it didn't click.
I don't make a habit to rummage through auto generated files very often so I never questioned that this may be the problem.
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