Error while running make autoannotate sundance_apps 4.3.7 - unix

I am trying to install opinionfinder and I getting stuck when i am trying to make autoannotate for sundance apps.
The error log I get is huge and it has all undefined reference errors.
The first line says in function 'my_init_sundance(sunstr,sunstr)' and a list of undefined reference errors.
Anyway i can solve it?
Thanks in advance.

Before trying to compile autoannotate you must make sure Sundance compiled successfully. Check that your sundance-4.37/bin contains: aslog nlp prepro
In order for Sundance to compile on my 64 bit machine I had to edit the Makefile files in both src and include and add -m32 to the CFLAGS variable (or the NormalCC). Also down after the shared_lib_linux: target. Since I am on OSX I also had to add -dynamic flat to NormalOpts and LIBS.

Related

Intel oneAPI dpcpp compiler with google test

I'm kinda new to the world of Intel's HPC toolchain and I'm facing some troubles making even simple DPC++ application to work when gtest is used as a testing framework
This is the CMakeLists "structure" I'm following
cmake_minimum_required(VERSION 3.14)
project(foo)
set(CMAKE_CXX_COMPILER "dpcpp")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++17 -O3 -fsycl")
# add executables
# target linked libraries
# ...
option(ENABLE_TESTS ON)
if(ENABLE_TESTS)
FetchContent_Declare(
googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG release-1.11.0
)
set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
FetchContent_MakeAvailable(googletest)
add_subdirectory(tests)
endif()
If I remove the last block, it compiles and runs as expected, otherwise I get the following error:
CMake Error at build/_deps/googletest-src/CMakeLists.txt:10 (project):
The CMAKE_CXX_COMPILER:
dpcpp
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
-- Configuring incomplete, errors occurred!
See also "/home/u141905/foo/build/CMakeFiles/CMakeOutput.log".
See also "/home/u141905/foo/build/CMakeFiles/CMakeError.log".
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_CXX_COMPILER= /usr/bin/c++
-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.
make: *** [Makefile:2: all] Error 1
Please notice that dpcpp is correctly set, in fact I'm using Intel's devcloud platform.
Setting CXXto the output of whereis dpcpp produces the same error.
The only "workaround" (I doubt it is one though) I found is using clang++ instead (the version from Intel's llvm). Any help or suggestion is much appreciated, thanks in advance!
EDIT: after some more attempts, I noticed that if I set CMAKE_CXX_COMPILER just after fetching gtest, everything works fine. Anyway I don't understand why this happens and how can be properly fixed.
Use the path for dpcpp binary for setting the CMAKE_CXX_COMPILER instead of using"set(CMAKE_CXX_COMPILER "dpcpp")". After adding the path("/opt/intel/oneapi/compiler/2022.0.1/linux/bin/dpcpp") to the CMAKE_CXX_COMPILER, you can run the program successfully.
Please find the below CMakeLists.txt for setting the CMAKE_CXX_COMPILER:
project(foo)
set(CMAKE_CXX_COMPILER "/opt/intel/oneapi/compiler/2022.0.1/linux/bin/dpcpp")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++17 -O3 -fsycl")
# add executables
# target linked libraries
# ...
set(ENABLE_TESTS ON)
include(FetchContent)
if(ENABLE_TESTS)
FetchContent_Declare(
googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG release-1.11.0
)
set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
FetchContent_MakeAvailable(googletest)
add_subdirectory(tests)
endif()
Thanks & Regards,
Hemanth
Did you run the source /opt/intel/oneapi/setvars.sh intel64 script? I.e. is dpcpp on your path before running cmake?

GOBJECT_INTROSPECTION_CHECK syntax error on configure

On "./configure" of an open source project I get:
user agent OS = Linux
./configure: line 13957: syntax error near unexpected token 0.9.3'
./configure: line 13957: GOBJECT_INTROSPECTION_CHECK(0.9.3)'
make: *** [config.status] Error 2
Ubuntu 12.04 package "gobject-introspection" and "libgirepository1.0-dev" are present. Removing the GOBJECT_INTROSPECTION_CHECK line allows configure to complete, but the project fails a dependency later.
How can I get past this configure step cleanly? Googling for this issue shows bugs filed against numerous OS projects for this same blocking issue, but the usual answer is "install gobject-introspection".
As the OP discovered on his own he had to install the gobject-introspection package to get the m4 macros that were being used.
The error message has the raw macro in it, as configure scripts are generated from configure.in/configure.ac files via m4/etc the fact that the raw macro is in the output file indicates that the macro did not get translated at generation time.
The gobject-introspection m4 files were apparently installed after autogen.sh (or equivalent) was run to generate the configure script. Re-running the autogen.sh script should regenerate the configure script and run the macro correctly.

Can't build libxml++

I have some legacy code which uses libxml++. I try to build it on RedHat:
./configure
make.
There is a compilation error in libxml++/parsers/parser.cc:
parser.cc:192: error: 'auto_ptr' is not a member of 'std'
If I include in this file, there are much more other errors.
Maybe I should pass some extra options for configure?
Anybody have a ready rpm with libxml++-2.6 for RedHat?
I included header memory in 2 files: libxml++/parsers/parser.cc, libxml++/parsers/textreader.h
After that I compiled the library.

error installing blitz++

I need blitz++ to run a 3rd party library, but I'm not being able to compile it. The ./configure command runs well and sets the Makefile, but when i make it produces the following error:
In file included from ../blitz/array/funcs.h:29:0,
from ../blitz/array/newet.h:29,
from ../blitz/array/et.h:27,
from ../blitz/array-impl.h:2515,
from ../blitz/array.h:32,
from ../src/globals.cpp:13:
../blitz/funcs.h: In static member function 'static blitz::Fn_abs<long int>::T_numtype blitz::Fn_abs<long int>::apply(blitz::Fn_abs<long int>::T_numtype1)':
../blitz/funcs.h:530:14: error: 'labs' is not a member of 'std'
../blitz/funcs.h:530:14: note: suggested alternative:
/usr/include/stdlib.h:772:17: note: 'labs'
make[1]: *** [globals.lo] Error 1
I followed the instructions and I can't figure why is this happening. I'm using Ubuntu 11.10 and blitz 0.9. Also, I tried with both gcc 4.4 and 4.6. Please help a noob on a workaround.
Blitz++ version 0.9 is seriously outdated. You will need to fetch the code in the source repository:
hg clone http://blitz.hg.sourceforge.net:8000/hgroot/blitz/blitz

illegal text reloc to non_lazy_ptr error while building in xcode 4 with libav* libraries

I'm trying to build a simple application that uses ffmpeg's libav* libraries in xcode 4 and getting the following error:
ld: illegal text reloc to non_lazy_ptr from /ffmpeg/temp/ffmpeg-0.8/builduni/lib/libavcodec.a(ac3.o) in _ff_ac3_bit_alloc_calc_psd for architecture i386
I've already tried to run ranlib -c libavcodec.a to fix this problem, but nothing happend.
One more thing: my libav* libraries are fat binaries (i386 + x86_64).
Any ideas what can it be?
I have the same error. Finally, I got the solution at
http://lists.apple.com/archives/unix-porting/2008/Jan/msg00027.html
just add other link flag:
-read_only_relocs suppress
* EXPLANATION * The two assembly commands load the absolutes address of _trail into R15. Doing so is fine if _trail is ultimately
in the same linkage unit. _trail is in libmodule.dylib. For this to
work, at runtime the dynamic loader (dyld) would have to rewrite the
two instructions. Normally dyld only updates data pointers. One work
around is to make libdyalog an archive (e.g. libdyalog.a) and link
that with pere.s. Then all the code would be in the same linkage unit,
so there would be no need for runtime text relocs. The runtime (dyld)
does support text relocs (updating instructions) for i386, but you
need to link with -read_only_relocs suppress.

Resources