I am trying to comple mod_auth_kerb for apache on mac os x 10.5.7. I get no compilation errors, but when apache tries to load it:
org.apache.httpd[95092]: httpd: Syntax error on line 160 of /private/etc/apache2/httpd.conf: Cannot load /usr/libexec/apache2/mod_auth_kerb.so into server: dlopen(/usr/libexec/apache2/mod_auth_kerb.so, 10): no suitable image found. Did find:\n\t/usr/libexec/apache2/mod_auth_kerb.so: mach-o, but wrong architecture
I have tried the following in the make file:
ARCHFLAGS='-arch ppc64'
CPPFLAGS = -I. -Ispnegokrb5 $(KRB5_CPPFLAGS) $(KRB4_CPPFLAGS) $(DEFS) -mpowerpc64 -mcpu=G5 -mtune=G5 -arch ppc64
LDFLAGS = $(KRB5_LDFLAGS) $(KRB4_LDFLAGS) $(LIB_resolv) -mpowerpc64 -mcpu=G5 -mtune=G5 -arch ppc64
CFLAGS = -mpowerpc64 -mcpu=G5 -mtune=G5 -arch ppc64
I have looked in these threads:
http://lists.apple.com/archives/unix-porting/2008/Mar/msg00061.html
http://objectmix.com/apache/690208-re-mod_auth_kerb-mac-os-x-10-5-client.html
I also changed this in the source:
from
krb5_rc_resolve_full
to
__KerberosInternal_krb5_rc_resolve_full
I cannot get apache to load it and it claims it is the wrong architecture. I think apache is 64 bit from the ground up in this version of mac server so that is probably the problem. I just don't know how to get through it.
Line 160 is a red herring in the httpd.conf file (it has ##).
I don't know how to compile it correctly and was hoping for help.
I have a G5 PPC 64.
Thank you.
EDIT:
What is odd is this:
otool -hv mod_auth_kerb.so mod_auth_kerb.so: Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 PPC64 ALL 0x00 BUNDLE 10 1328 NOUNDEFS DYLDLINK TWOLEVEL
So I don't know what's wrong.
I am on the PPC64 and that's what it looks like I have compiled.
If i'm following the question correctly, I think you will need to build/install a cross compiling toolchain to build it from PPC to x86_64 or another non-PPC architecture, or even in some cases, PPC to PPC64 and vice-versa.
I would not advise this if you are unfamiliar with GCC, the Unix toolchain and the Darwin foundation stuff in general.
You might be able to find Darwin toolchain setups on the web. Some links in the right direction:
http://lists.apple.com/archives/darwin-development/2002/Dec/msg00062.html
http://ranger.befunk.com/fink/darwin-cross/
http://myownlittleworld.com/miscellaneous/computers/darwin-cross-distcc.html
http://www.google.com/search?q=Darwin+cross+compilation
Related
I have been able to install and start a program with CMake (with HDF5) but once I access the "about" drop-down link for said program it crashes with the following error:
python: symbol lookup error: /nobackup/<user id>/program-devel/dist_linux/bin_linux/libprogramDLL.so: undefined symbol: h5lib_MP_h5get_libversion_f_
I believe it is an issue with linking static libraries but I am, unfortunately, quite new to CMake and unable to isolate the root problem. I know that this "symbol" is tied somehow to a libhdf5_fortran.a and this is listed in my Cache with:
$ grep -rnw '/nobackup/<user id>/program-devel/build' -e "libhdf5_fortran"
/nobackup/<user id>/program-devel/build/CMakeCache.txt:234:ToolkitLib_LIB_DEPENDS:STATIC=general;SomeLib;general;libz.a;general;libhdf5.a;general;libhdf5_fortran.a;
I’m not sure if this might be where the problem is or not but this is from the ToolKit file - CMakeLists.txt.
if (${USE_HDF5})
#link_directories (${HDF5_DIRECTORY}/lib)
if (WIN32)
target_link_libraries(ToolkitLib libszip libzlib libhdf5 libhdf5_f90cstub libhdf5_fortran)
else ()
# doesn't seem to work on Linux for some reason....
#target_link_libraries(ToolkitLib libsz libz libhdf5 libhdf5_fortran)
# ... try this ... seems to be getting the shared libs...not the static ones...
# set(HDF5_LINK_FLAGS "-L${HDF5_DIRECTORY}/lib -lz -lhdf5_fortran -lhdf5")
# SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${HDF5_LINK_FLAGS}")
# SET(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${HDF5_LINK_FLAGS}")
# ... doesn't work either ...
target_link_libraries(ToolkitLib libz.a libhdf5.a libhdf5_fortran.a)
endif()
endif()
The last 4 "target_link_library" elements are in directories I've added to my LD_LIBRARY_PATH (although, I've heard this isn't the preferred approach). There is also a final output line when I issue gmake install that might be relevant:
-- Set runtime path of "/nobackup/<user id>/program-devel/dist_linux/bin_linux/libProgramDLL.so" to "$ORIGIN/"
It seems I fixed my problem by adding a --with-pic on the hdf5 installation bash scripts. I also had to remove a -standard-semantics from the CMAKE_Fortran_FLAGS in the src directory. Those two things along with the help you provided fixed my problem. Thanks a lot Pierre de Buyl!
I am trying to build mpich 3.1.3. in a Mac OSX 10.10 Yosemite with Xcode 6.1 and intel compilers icc and ifort version 15.0.0 20140716. I get an error when I am building the installation. The error is the following:
GEN lib/libpmpi.la
ifort: command line warning #10006: ignoring unknown option '-force_load,src/mpl/.libs/libmpl.a'
ifort: command line warning #10006: ignoring unknown option '-force_load,/Users/alejandrodelacallenegro/Downloads/mpich-3.1.3/src/openpa/src/.libs/libopa.a'
ifort: command line warning #10006: ignoring unknown option '-force_load,src/mpi/romio/.libs/libpromio.a'
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: object: lib/.libs/libpmpi.a(initthread.o) malformed object (section contents at offset 0 with a size of 1056, overlaps Mach-O headers at offset 0 with a size of 768)
I do not understand where the error come from, from the compiler or from libtool. I have also attached the outputs of the configuration and the build steps.
I finally found the cause of the problem. libtool was somehow corrupted, so I install it again, and then I don't get this error anymore. I have install Xcode again, but I suppose that installing it from macports, homebrew or from source solves the problem as well.
Alex
I recently had it pointed out to me that I might have OpenNI installed correctly but PCL is unable to access it. I've been trying to use various packages with the Kinect and when cmake compiling I always encounter the same error:
-- checking for module 'openni-dev'
-- package 'openni-dev' not found
-- Could NOT find openni (missing: OPENNI_INCLUDE_DIRS)
** WARNING ** io features related to openni will be disabled
I used printenv and received this output:
printenv
SSH_AGENT_PID=2570
GPG_AGENT_INFO=/tmp/keyring-xXJFL7/gpg:0:1
TERM=xterm
SHELL=/bin/bash
ROS_ROOT=/opt/ros/hydro/share/ros
XDG_SESSION_COOKIE=aa6e36316433d5c21f6f3b1500000008-1400098211.848077-377195861
ROS_PACKAGE_PATH=/opt/ros/hydro/share
ROS_MASTER_URI=http://localhost:11311
WINDOWID=56623110
GNOME_KEYRING_CONTROL=/tmp/keyring-xXJFL7
USER=robot2
LD_LIBRARY_PATH=/opt/ros/hydro/lib
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
CPATH=/opt/ros/hydro/include
SSH_AUTH_SOCK=/tmp/keyring-xXJFL7/ssh
SESSION_MANAGER=local/robot2-Precision-T7600:#/tmp/.ICE-unix/2535,unix/robot2-Precision-T7600:/tmp/.ICE-unix/2535
DEFAULTS_PATH=/usr/share/gconf/ubuntu.default.path
XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/etc/xdg
PATH=/opt/ros/hydro/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
DESKTOP_SESSION=ubuntu
PWD=/home/robot2
GNOME_KEYRING_PID=2524
LANG=en_US.UTF-8
MANDATORY_PATH=/usr/share/gconf/ubuntu.mandatory.path
UBUNTU_MENUPROXY=libappmenu.so
COMPIZ_CONFIG_PROFILE=ubuntu
GDMSESSION=ubuntu
SHLVL=1
HOME=/home/robot2
ROS_DISTRO=hydro
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
PYTHONPATH=/opt/ros/hydro/lib/python2.7/dist-packages
LOGNAME=robot2
XDG_DATA_DIRS=/usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-DdLQNdIXso,guid=2440d412c31af4bd219f648600000030
PKG_CONFIG_PATH=/opt/ros/hydro/lib/pkgconfig
LESSOPEN=| /usr/bin/lesspipe %s
CMAKE_PREFIX_PATH=/opt/ros/hydro
DISPLAY=:0.0
XDG_CURRENT_DESKTOP=Unity
LESSCLOSE=/usr/bin/lesspipe %s %s
ROS_ETC_DIR=/opt/ros/hydro/etc/ros
COLORTERM=gnome-terminal
XAUTHORITY=/home/robot2/.Xauthority
_=/usr/bin/printenv
Does anyone have any ideas? Is this potentially a path issue?
It seems you have installed OpenNI into some non-standard ocation, that's why CMake can't locate it. Help it by setting CMAKE_PREFIX_PATH to the dir where OpenNI's include/ is located.
I have added libpng to my application. If I build for simulator, everything is OK. When I build application for device, I got linker error:
Undefined symbols for architecture armv7: "_png_init_filter_functions_neon", referenced from: _png_read_filter_row in libpng-arm7-release.a(pngrutil.o)
I have build libpng manually from source, same way for simulator and device (only with changed target of compilation). I have tried to find this problem, but noone seems to post anything about this problem.
I "solved" this by replacing lines 117-121 in libpng's pngpriv.h:
# ifdef __ARM_NEON__
# define PNG_ARM_NEON_OPT 2
# else
# define PNG_ARM_NEON_OPT 0
# endif
by
#define PNG_ARM_NEON_OPT 0
This disables ARM's NEON optimizations, which seems to be the cause of the problem.
This is merely a workaround though, I didn't have time to investigate the real cause of the problem further.
Adding to PSyton's comment, here is how we solved it.
Compile the arm/*.c files. This however does only work for Android. For iOS, we additionally had to create a new pnglibconf.h with the entries:
#undef PNG_ARM_NEON_API_SUPPORTED
#undef PNG_ARM_NEON_CHECK_SUPPORTED
#define PNG_ARM_NEON_OPT 0
Looking at the ARM defines in libpng, it seems like they are a bit buggy currently, as PNG_ARM_NEON_API_SUPPORTED should be sufficient to turn NEON compilation off.
I experienced a similar error on macOS.
After getting libpng from the source
https://sourceforge.net/projects/libpng/files/
and compiling with the PNG_ARM_NEON option off, the error disappeared.
I have two Free Pascal units that I would like to use from a C program on linux.
Here is what I do:
$ fpc -fPIC base64.pas queueutils.pas
Warning: Only one source file supported
Free Pascal Compiler version 2.2.2 [2008/11/05] for x86_64
Copyright (c) 1993-2008 by Florian Klaempfl
Target OS: Linux for x86-64
Compiling queueutils.pas
queueutils.pas(2088,11) Warning: Symbol "Socket" is deprecated
queueutils.pas(2097,10) Warning: Symbol "Connect" is deprecated
queueutils.pas(2104,3) Warning: Symbol "Sock2Text" is deprecated
2432 lines compiled, 0.5 sec
4 warning(s) issued
$ ppumove -o queueutils -e ppl *.ppu
PPU-Mover Version 2.1.1
Copyright (c) 1998-2007 by the Free Pascal Development Team
Processing base64.ppu... Done.
Processing queueutils.ppu... Done.
Linking queueutils.o base64.o
Done.
Seems fine so far, libqueueutils.so is created:
$ file libqueueutils.so
libqueueutils.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
$ ldd libqueueutils.so
ldd: warning: you do not have execution permission for `./libqueueutils.so'
statically linked
However when the C program tries to use the library this way:
libqueue = dlopen("./libqueueutils.so", RTLD_LAZY);
if (!libqueue) {
fprintf (stderr, "%s\n", dlerror());
}
it yields an error message:
$ ./tmbrkr
./libqueueutils.so: undefined symbol: VMT_PROCESS_TPROCESS
This VMT_PROCESS_TPROCESS-related error is resolved if I add process.o and process.ppu to the linking process done by ppumove. However after doing so another unit is missing and after that another... You get it.
Is there a way to somehow link all the necessary units together in one .so file so that the C program can dlopen() the library properly?
Just like a normal binary (exe) is from a "program" source file , a .so/dll is created from a ''library'' sourcefile.
For the rest is the model is the same. You simply build the library mainprogram, and the compiler collects all units necessary and stuffs them in the .so.
With the exports keyword you can define what symbols to export.
library testdll;
uses x,y,z;
// define exportable symbols here
// some examples of symbol exports
exports
P1 index 1, // dll based on index
P2 name 'Proc2', // normal export with alternate external symbol
P3, // just straight export.
P4 resident // for some MCU use
;
begin
// startup code
end.
Also look up $soname $libsuffix and $libprefix in the manual.
Though I would recommend just using most recent 2.6.0, not some 5 year old 2.2.2
It might require recompiling FPC first with PIC though.