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}

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

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 defines main().

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