My specs:
OS: Ubuntu 10.04 LTS amd64
fpc: 2.4.0
lazarus: 0.9.28
I'm trying to compile a WebLaz project just by creating one and then compiling.
Somehow the compiler gets all lost when determinig witch httpd and fpapache Units to use.
I've found similar problems in the forums:
mod_helloworld.lpr Can't find fpapache Unit ...
I NEED HELP with fpweb ...
After trying some of the solutions provided there I'm still at this point:
Project compiles fine if I only have httpd22 under the Compiled units and the Source for the packages. Alas it then completely fails to link.
With the original fpc/lazarus folder structure (Having all of HTTPD13, HTTPD20 and HTTPD22 untouched on both locations, units and source) the compiler complains that checksum of httpd has changed and the fails to find fpapache's source.
It finds httpd.pas under httpd20 but then it only works with folders for 2.2
I'm completely lost as how to compile this using the WebLaz component, what am I missing?
Probably you need to select the version you want, and then rebuild the relevant lazarus parts, so that the pkgs get build with the then selected apache.
Afaik the selection of the httpd daemons is simply changing order, it doesn't mean that all versions are supported at once, like e.g. mysqlconnection does.
From what I could investigate from the, very verbose, output using the Test button on the "Compiler Options" none for these option are defined:
FPCAPACHE_1_3
FPCAPACHE_2_0
So this means that in: /etc/fpc.cfg
#IFDEF FPCAPACHE_1_3
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/httpd13/
#ELSE
#IFDEF FPCAPACHE_2_0
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/httpd20/
#ELSE
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/httpd22/
#ENDIF
#ENDIF
The test will revert to httpd22 by default.
None the less, having:
/usr/lib/fpc/2.4.0/units/x86_64-linux/httpd20
/usr/lib/fpc/2.4.0/units/x86_64-linux/httpd22
in the compiler's path to compiled units it means that it will find httpd20 first.
This means it will try to load the 2.0 version and not the 2.2 version of the compiled units.
So the first solution is to delete/move the 1. folder from the system.
This will let you compile, but alas it will not link on a 64 bit system (I'm testing on a AMD64 system so I'm not going to presume it works elsewhere).
The process ends with a hint, to add -fPIC to the compiler options.
If you go to Project->Compiler Options...->Other on the lower TextBox you can add it.
Voila, it's working.
Related
I have been trying to go through this tutorial and I always get stuck in the second build of GCC when making the cross-toolchain. It errors out saying that I am attempting to call a poisoned calloc. I have gone through several patches and what they all seem to do is just #include the offending system header (in this case pthread.h) earlier in the source code. Since there are no patches for my particular problem, I have gone ahead and emulated their solutions in my case. While this works (compilation now fails because I don't have some ISL files) it feels like a hack, and I suspect that the root problem is further back in the build.
Thus, I wanted to ask:
Why are symbols poisoned? Why would the GCC maintainers want some symbols not to be used?
What are the general causes for this problem? Is it really just a bug or is this a problem that arises in more general situations?
I am more interested in the generalities of this issue, but if it helps, I am using the latest release of Alpine Linux (with gcc 12.2.1) trying to compile gcc 11.2
.0 for the same target architecture as the host (x86-64).
I have tried many methods to build a 32-bit version of OpenCV version 4.0.1, however to no avail. I have tried using CMake and the file I require is opencv_world401.dll
May I know if anyone has any steps for me to follow to build the 64 bit source code so that I can have a complete 32-bit package in return? It seems there will be missing files when I use CMake.
Thank you!
Tried using CMake to build the 64 bit source code into a 32 bit package
Currently OpenCV_world401.dll is giving me a winerror 193
I have the same problem. It would be resolved easily. Firt, you need to download your intended version, in this case, under OpenCV – 4.1.2 section choose Windows from https://opencv.org/releases/.
Then, download the executable file, run it, and extract it wherever you want. Afterward you will be able to find, for example, opencv_world401.dll under "opencv\build\x64\" folder.
The opencv source code is platform in-dependent, which means you can build dll/so files for different platform with this same source code tree. But to get a Win32 build you'll have to make some change during "Configuration" step, because by default it will generate a x64 platform build.
Basically that's the only change required.
If you can read Chinese, here's a detailed tutorial for you to reference:
https://www.csdn.net/tags/OtDaQg0sODk1MS1ibG9n.html
TLDR at the bottom.
I've been running an application I've found on codeplex.com called PCSXR. However, I believe a Windows update has caused the program not to function properly or it's missing some Windows Visual Basic add-on since it was fine before I cleaned installed Windows 10 for fixing a problem that recovery couldn't fix.
I've tried version 1.9.92 executable but it has crash issues playing cinematics.
Version 1.9.93, which is most stable and I was using, no longer can read the DLL plugins in the folder. Making it unusable.
After browsing around. I found this post that this person solved the problem using Dev C++ to compile the source code. I've attempted to build it but I keep getting thrown errors. Wrong architecture which I've solved by setting it to 32 bit compile but other errors prevented it compiling.
After Googling how-to around and talking with some other programmers. I've been going back and forth with different tools on how to compile it. Code Blocks, Dev C++, MinGW and an old Git program on Windows to run Bash. I even ended up having missing config.h which is in the header and even winres.h missing.
I somehow managed to compile it through WSL (Windows Subsystem for Linux) with Ubuntu, XFCE4 Desktop through VcXsrv to display XFCE4 through a window. PCSXR starts, has plugins but crashes when I run it. From what I've been told, the error due to WSL not supporting sound. So WSL failed.
I've tried Ubuntu "Try It" CD environment but fails to compile at all.
VirutalBox on latest version no longer works since they disabled it working on my machine since it doesn't have BIOS virtualization setting.
TLDR
I've been following their program documentation but it's not really detailed for Windows users.
So my question is: How do I build, in detailed steps, PCSXR either from updated source code here or 1.9.93 source here into a working Windows executable with its DLL plugins working? What programs I need, what do I type in what, what settings, where I find missing files etc.
I know this isn't probably the best question here but I've been at this for 2 whole days, Googling and asking.
I'm using Windows 10, AMD CPU, 64 bit with no BIOS virtualization support.
I managed to do it by following these steps on this forum post:
You need Dev C++ 5.11.
1).Go to File>Open>Directory of Pcsxr>win32>pcsxr.dev
2).Under Project select pcsxr. Right click and select project options.
3.In Project Options select compiler. Set Base compiler to "TDM-GCC 4.9.2 32bit Release" then click ok.
4).In the main menu of Dev C++ 5.11 look for Execute. Select Compile.
5).Wait for it to compile. If you were successful there should a
pcsxr.exe in pcsxr source directory>win32.
After following the steps and trying out all the most recent versions of the source codes available. This is my research results I posted after.
Thanks for the reply. It really helped a lot.
I've tried the 1.9.93 beta source code "pcsxr-1.9.93.tar.bz2"
(extracted with 7zip) and got a compile error about "#include
" not found.
I've tried the 1.9.94 alpha source code "pcsxr-1.9.94.zip" and it
compiled successfully. I got a "pcsxr\libpcsxcore\gte_divider.h"
missing error when loading the dev file in win32 folder but it seems
to work okay.
I've tried the up-to-date source code (last modification Feb 18, 2017)
and it compiled successfully. I got a
"pcsxr\libpcsxcore\gte_divider.h" missing error when loading the dev
file in win32 folder but it seems to work also. The background logo
that covers the main window seems to be blank grey until I start a
game.
I solved the winres.h issue by getting this missing Windows h Sample
file from github here:
https://github.com/Microsoft/Window...les/Win7Samples/winui/tsf/tsfcompart/winres.h
and just added it to the root of the project folder. I had to replace
'#include ' with '#include "winres.h"'.
I don't know about the built-in plugins source code. Some don't have a
dev file and they always throw errors when compiling. I've managed to
add working third party ones from emulator zone and the ones from
1.9.93 beta release "pcsxr-1.9.93-win32.zip" and managed to get 1.9.93 working great.
I have some C++ code using NEON intrinsics. From what I have read, all you need to do is include arm_neon.h to your project.. And then I read that this arm_neon.h header is not actually readily available to you automatically, you have to get it from the web. So I found and added this version to my project:
http://clang.llvm.org/doxygen/arm__neon_8h-source.html
In my project's prefix.pch I added:
#import "arm_neon.h"
And when I try to build on my iPhone6 device (I am not using the simulator), I get a billion errors inside the arm_neon.h file:
Can anyone please explain to me what I am missing here?
You've been misinformed about being able to pick up an arm_neon.h from the Internet. Generally the header is not just compiler specific, but compiler version (even compiler revision) specific. For GCC it relies on a number of compiler built in function calls, and from your screenshot of Clang the same holds there. As you'd expect, if the name of these internal-only functions changes, the header will fail to compile.
What surprises me is that you're unable to use an include of whichever arm_neon.h ships with your build environment. The only thing I can think of that would cause this is the build command trying to build for x86_64 (for the simulator) but you say this isn't what is happening. It might be worth checking your build settings one more time.
If you're still not getting anywhere, remember that arm_neon.h is sometimes considered as a system header, so in C++ you might need to #include <arm_neon.h> rather than #include "arm_neon.h" to get the compiler to search the system paths.
I'm trying to port some very old fortran code to windows. I'd like to use mingw and f2c, which has no problem converting the code to usable C on OS X and Ubuntu. I used f2c.exe as distributed by netlib on a fresh install of mingw, and it translated the code fine. I have a "ported" version of libf2c that seems to still contain some unresolved references -- mostly file i/o routines (do_fio, f_open, s_wsfe, e_wsfe) and, peculiarly, one arithmetic routine (pow_dd). To resolve these issues, I tried to build libf2c from source, but ran into an issue during the make process. The make proceeds to dtime_.c, but then fails due to a dependency on sys/times.h, which is no longer a part of the mingw distro. There appears to be a struct defined in times.h that defines the size of a variable in dtime_.c, specifically t and t0 on lines 53 and 54 (error is "storage size of 't' isn't known"; same for t0).
The makefile was modified to use gcc, and make invoked with no other options passed.
Might anyone know of a workaround for this issue? I feel confident that once I have a properly compiled libf2c, I'll be able to link it with gcc and the code will work like it does on linux and os X.
FOLLOW-UP: I was able to build libf2c.a by commenting out the time related files in the makefile (my code does not contain any time related functions, so don't think it will matter). I copied it to a non-POSIX search directory as show in -print-search-dirs, specifically C:\MinGW\lib\gcc\mingw32\3.4.5. That seems to have fixed the issue on the unresolved references, although the need to eliminate the time files does concern me. While my code is now working, the original question stands -- how to handle makefiles that call for sys/times.h in mingw?
Are you sure the MinGW installation went correct? As far as I can tell the sys/times.h header is still there, in the package mingwrt-3.18-mingw32-dev.tar.gz. I'm not familiar with the gui installer, but perhaps you have to tick a box for the mingwrt dev component.