i followed the instruction of below link.
http://www.rdbprime.com/Documentation/WebObjects/Deployment/Deploying_Applications/Installation/Building_the_Adaptors.html
But I'm getting the following error when I am compiling Apache Adaptor.
c: not found
make[1]: [mod_WebObjects.so] Error 2 (ignored)
strip mod_WebObjects.so
strip: not found
make[1]: *** [mod_WebObjects.so] Error 2
make: *** [Apache] Error 2
The documentation you provided is very old, are you sure you wan't to build such an old adapter? WebObjects has moved to Java a long time ago and the Adapter has changed a lot since then.
For example you can find current information about compiling it for Linux here:
http://wiki.wocommunity.org/display/documentation/Compiling+the+HTTP+adaptor+on+Linux
Related
I'm trying to install omnet++ 5.6.2 but after writing "make" in the command line below error was showing me.
please help me how can solve this problem
Create executable: out/clang-release//embedding.exe
ln: failed to create symbolic link './embbedding.exe': no such file or directly
make[2]: *** [Makefile:87: embedding.exe] Error 1
make[1]: *** [Makefile:134: embedding] Error 2
make: *** [Makefile:28: allmodes] Error 2
Try to turn off a real-time antivirus protection during compilation.
I am new to bitcoin core development. I have created a clone using bitcoin core version v0.15.0rc3 on a mac os high sierra 10.13.2. I am have installed all dependencies and am able to run the autogen.sh and configure with no errors. However, when I run make I am getting the following error.
2 errors generated.
make[2]: *** [libbitcoin_server_a-miner.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
You can see the full error in pastebin https://pastebin.com/M7tNaiMM
I have been trying to resolve the issue for 2 days and cannot find a solution.
The issue was with the Const not being labelled outside of the function parameters. Found the issue resolution on github but looks like they have not added the change to bitcoin core code yet.
update the miner.h file and the txmempool.h file with const
https://github.com/litecoin-project/litecoin/commit/1ec0c0a01c316146434642ab2f14a7367306dbec
I'm trying to compile gcc-code-assist which has the code completion feature in order to use it with emacs. However i have been getting this error message while compilinng
checking for exception model to use... configure: error: unable to detect exception model
make[1]: *** [configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/home/dev/workspace/trash/gcc-code-assist-0.1-4.4.4'
make: *** [all] Error 2
I'm running Ubuntu 12.04 64bit
what can i do to overcome this problem
I found the right way to compile it ...
I really didn't have much knowledge of how to compile gcc (my first time)
after reading through the FAQ of building gcc I found the problem.
it turned out that I had to run the configure script and make from outside the source directory
( I called it gcc-build) so the directory list looked like this
gcc-source/
gcc-build/
then everything compiled smoothly
here's the link to the FAQ http://gcc.gnu.org/wiki/FAQ#configure
I am trying to compile GCC for Cygwin with support for targeting i386-elf so I can compile some simple OSes (search Benu, by l30nard0, on Github). I've successfully compiled the binutils for i386-elf, and compiled all of GCC's floating-point numbers dependencies.
Problem is, it says windows.h can not be found. I do have w32api successfully installed, and tried including each of those one at a time in the include path for GCC, but none of them work. If I try any of them, I get so many errors and warnings that not all will show up in the Cygwin console. The dozens upon dozens of warnings are most if not all unused parameter.
Does anyone know where the problem might lie?
I've wasted the last three entire days of my life trying to get Linux Mint set up with everything I want, but for reasons I shan't go into I gave up on that. I'd love to be able to get just one thing to work so I can enjoy my life again. :) Thanks!
BTW: The configure arguments I used were --target=i386-elf --enable-threads=win32 --enable-languages=c,c++ Was I supposed to use --enable-targets instead?
And here's part of the log:
In file included from ../../../gcc/libgcc/gthr.h:150:0,
from ../../../gcc/libgcc/unwind-dw2.c:38:
./gthr-default.h:541:21: fatal error: windows.h: No such file or directory
compilation terminated.
../../../gcc/libgcc/static-object.mk:17: recipe for target 'unwind-dw2.o' failed
make[2]: *** [unwind-dw2.o] Error 1
make[2]: *** Waiting for unfinished jobs....
In file included from ../../../gcc/libgcc/gthr.h:150:0,
from ../../../gcc/libgcc/unwind-dw2-fde.c:38:
./gthr-default.h:541:21: fatal error: windows.h: No such file or directory
compilation terminated.
../../../gcc/libgcc/static-object.mk:17: recipe for target 'unwind-dw2-fde.o' failed
make[2]: *** [unwind-dw2-fde.o] Error 1
make[2]: Leaving directory '/home/Sean/gccbuild/i386-elf/libgcc'
Makefile:10055: recipe for target 'all-target-libgcc' failed
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory '/home/Sean/gccbuild'
Makefile:870: recipe for target 'all' failed
make: *** [all] Error 2
Remove the --enable-threads=win32 flag; it is intended to specify thread support on the target system, not the build system.
everything is in the tittle.
I've made some research on the subject and found this : http://fedoraproject.org/wiki/Features/Windows_cross_compiler.
I've followed the steps one by one, reaching the "How to set" part but when I try to compile (as the Mingw README said make MINGW_HOST=x86_64-w64-mingw32) I obtain this :
...
File "topfind.ml", line 171, characters 4-27:
Error: Unbound module Toploop
make[2]: *** [topfind.cmo] Error 2
make[2]: Leaving directory `/local/aturbin/mingw32-ocaml/build/findlib/src/findlib'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/local/aturbin/mingw32-ocaml/build/findlib'
make: *** [stamp-build-findlib] Error 2
Any ideas about what's going wrong ?
Proper cross-compilation for OCaml currently requires a set of patches which you can find at http://caml.inria.fr/mantis/view.php?id=5737 ; the patches are being integrated in the trunk version of ocaml right now, so I guess that bug report should contain the latest information.