Problem compiling/linking c++ library on Snow Leopard
I am currently trying to recompile the code for an abandoned c++ library I used as a graduate student to perform scientific calculations. I have successfully updated the code and compiler flags to deal with changes that have been made in versions of the g++ compiler since the source code was last updated and am now able to compile the library without errors. I am now encountering an error when I try to execute a wrapper script that sets up various parameters for compiling c++ code using this library.
The library compiles without error:
% make clean && make
[…]
c++ -c -I../../src -ffriend-injection -fno-common ../../src/Testing/ModTest.cc -o ../../i386-apple-darwin10.2.0/ModTest.soo
c++ -c -I../../src -ffriend-injection -fno-common ../../src/Testing/GamTest.cc -o ../../i386-apple-darwin10.2.0/GamTest.soo
Making Shared Library libgamma.dylib From Object Files
======================================================
* Building Library ../../i386-apple-darwin10.2.0/libgamma.4.1.0.dylib
* Linking ../../i386-apple-darwin10.2.0/libgamma.4.dylib To This Library
* Linking ../../i386-apple-darwin10.2.0/libgamma.dylib To This Library
The error that I get when trying to execute the wrapper script which calls the newly compiled library:
% ./gamma
G A M M A
g++ -Wall -I/Users/mlgill/research/local/gamma-4.1.0/src -D_GAMMA_SRC_=/Users/mlgill/research/local/gamma-4.1.0/src -L/Users/mlgill/research/local/gamma-4.1.0/i386-apple-darwin10.2.0 -lgamma -lm
ld: warning: in /Users/mlgill/research/local/gamma-4.1.0/i386-apple-darwin10.2.0/libgamma.dylib, file is not of required architecture
Undefined symbols:
"_main", referenced from:
start in crt1.10.6.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
A brief search on the internet for this error along with "Snow Leopard" seems to indicate this is an issue with either compilation or linking of 64-bit instead of 32-bit libraries. I have tried several possible combinations of promising compilation flags, including "-m32", "-arch i386", and "-march=i386" in both the Makefile and the wrapper script. I've also tried combining these flags together in several cases. I know that the flags are being set during both the compilation and the wrapper script because I see them in the output, e.g:
c++ -c -I../../src -m32 -ffriend-injection -fno-common ../../src/Testing/GamTest.cc -o ../../i386-apple-darwin10.2.0/GamTest.soo
and
g++ -Wall -m32 -ffriend-injection -I/Users/mlgill/research/local/gamma-4.1.0/src -D_GAMMA_SRC_=/Users/mlgill/research/local/gamma-4.1.0/src -L/Users/mlgill/research/local/gamma-4.1.0/i386-apple-darwin10.2.0 -lgamma -lm
I also get an error ("error: CPU you selected does not support x86-64 instruction set") when I try to compile the library with only "-march=i386" set, which further demonstrates the flags are being recognized.
Unfortunately, I have thus far been unsuccessful in getting the wrapper script to run without error. Does anyone have any suggestions for how to get this compilation and/or wrapper script to work?
I am a biophysicist and have no formal training in programming, so I apologize if any of this is unclear. I have compiled a reasonable number of programs (mostly on 32-bit systems), so I am somewhat experienced with makefiles, etc.
I have posted some other relevant information below, including the output of otool on the appropriate libraries and relevant portions of the Makefile and wrapper script. Please let me know if I can provide any other information.
Thank you!
Michelle Gill
Output from otool
% otool -h -L ./libgamma.dylib
./libgamma.dylib:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
0xfeedface 7 3 0x00 6 10 1608 0x00118085
../../i386-apple-darwin10.2.0/libgamma.4.dylib (compatibility version 4.1.0, current version 4.1.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0)
% otool -h -L /usr/lib/libstdc++.6.dylib /usr/lib/libSystem.B.dylib
/usr/lib/libstdc++.6.dylib:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
0xfeedface 7 3 0x00 6 11 1636 0x00118085
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)
/usr/lib/libSystem.B.dylib:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
0xfeedface 7 3 0x00 6 11 1784 0x00000085
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0)
/usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 315.0.0)
Relevant portions of the Makefile for the library
BINDIR = ../../i386-apple-darwin10.2.0
SO_BASE = libgamma
SO_NAME = ${SO_BASE}.dylib
CXX = c++
SOCPPFLAGS = -I../../src -ffriend-injection -m32
SOCXXFLAGS = -fno-common
SO_LDFLAGS = -dynamiclib -m32
BASICS = Basics
MATRIX = Matrix
[…] # NOTE the source code directory contains a series of corresponding directories, each containing source files
# Only two are listed for brevity.
include ../../make/MakeMods # NOTE that this file contains list of files found in above directories
${BINDIR}/%.soo : ${SOURCEDIR}/${BASICS}/%.cc
$(CXX) -c $(SOCPPFLAGS) $(SOCXXFLAGS) $< -o $@
${BINDIR}/%.soo : ${SOURCEDIR}/${MATRIX}/%.cc
$(CXX) -c $(SOCPPFLAGS) $(SOCXXFLAGS) $< -o $@
[..] # NOTE these commands continue for each of the subdirectories of the main source code directory
$(BINDIR)/$(SO_NAMEXXX): $(SO_OBJS)
@echo
@echo "Making Shared Library $(SO_NAME) From Object Files"
@echo " ======================${SO_NAUL}=================="
@echo
@echo " * Building Library ${BINDIR}/${SO_NAMEXXX}"
@g++ ${SO_LDFLAGS} -install_name ${BINDIR}/${SO_NAMEX} \
-compatibility_version ${COMPVER} -current_version ${CURRVER} \
-o ${BINDIR}/${SO_NAMEXXX} ${SO_OBJS} $(SO_LDLIBS)
@rm -f ${BINDIR}/${SO_NAMEX} ${BINDIR}/${SO_NAME}
@echo " * Linking ${BINDIR}/${SO_NAMEX} To This Library"
@ln -s ${BINDIR}/${SO_NAMEXXX} ${BINDIR}/${SO_NAMEX}
@echo " * Linking ${BINDIR}/${SO_NAME} To This Library"
@ln -s ${BINDIR}/${SO_NAMEXXX} ${BINDIR}/${SO_NAME}
Relevant portions of the wrapper script which calls the library
GAMMA_PATH=${GAMMA_PATH-/Users/mlgill/research/local/gamma-4.1.0}
CXX="g++"
CXXFLAGS="-m32 -ffriend-injection -g -O2"
src='src'
host='i386-apple-darwin10.2.0'
GAMMA_SRC=${GAMMA_PATH}/${src}
GAMMA_LIB=${GAMMA_PATH}/${host}
${CXX} -Wall ${CXXFLAGS} ${ARG} -I${GAMMA_SRC}\
-D_GAMMA_SRC_=${GAMMA_SRC}\
-L${GAMMA_LIB} -lgamma -lm ${NAME}




no main()?
I've got no idea what causes the problem with the different architectures, but I think there is another problem you should try to fix first: Actually, the "...not of required architecture" when you execute ./gamma is just a warning, the real error is this:
Undefined symbols:
"_main", referenced from:
The output of your script shows this:
g++ -Wall -I/Users/mlgill/research/local/gamma-4.1.0/src -D_GAMMA_SRC_=/Users/mlgill/research/local/gamma-4.1.0/src -L/Users/mlgill/research/local/gamma-4.1.0/i386-apple-darwin10.2.0 -lgamma -lm
Well... you are not compiling anything here (there are no source files), all you do is linking libgamma and libm. No wonder the compiler is missing main() :o)
In the source code of the script you have
${CXX} -Wall ${CXXFLAGS} ${ARG} -I${GAMMA_SRC}\
-D_GAMMA_SRC_=${GAMMA_SRC}\
-L${GAMMA_LIB} -lgamma -lm ${NAME}
Looks like
${NAME}is not defined... I guess it should contain the name of some source file that definesmain().If the architecture problem persists after this has been fixed: Could you post the output of "
file libgamma.dylib"?Hope that helps,
Stefan
Hi Stefan, Thank you for
Hi Stefan,
Thank you for your kind reply. I actually figured out the issue this afternoon. It pertained to a number of problems with libraries. You are, however, correct that I was not running the wrapper script with any source code for it to compile.
When I used this library (and accompanying wrapper script) in graduate school, it used to produce a different error when run without a program. It seems that compiling it myself (or perhaps differences between the obsolete binaries and the source code I was able to find) might be the reason for the difference.
Kindest regards,
Michelle Gill