Why can't I compile with OpenBSD? - c

My program used to compile fine with OpenBSD before I added the lemon parser. Now it compiles on Linux but on OpenBSD I get an error I don't understand.
$ cmake ..
-- The C compiler identification is GNU 4.2.1
-- The CXX compiler identification is GNU 4.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/dac/test/openshell/build
$ make
Scanning dependScanning dependencies of target shell
[ 28%] Building C object CMakeFiles/shell.dir/main.c.o
/home/dac/test/openshell/main.c: In function 'main':
/home/dac/test/openshell/main.c:788: warning: implicit declaration of function 'add_history'
/home/dac/test/openshell/main.c: In function 'command':
/home/dac/test/openshell/main.c:573: warning: passing argument 1 of 'expandVariable' discards qualifiers from pointer target type
cc: -ledit: linker input file unused because linking not done
cc: -lncurses: linker input file unused because linking not done
cc: -lcurses: linker input file unused because linking not done
cc: -ltermcap: linker input file unused because linking not done
[ 42%] Building C object CMakeFiles/shell.dir/shellparser.c.o
/home/dac/test/openshell/shellparser.c:280: error: expected expression before '%' token
/home/dac/test/openshell/shellparser.c:288: error: expected expression before '%' token
/home/dac/test/openshell/shellparser.c:288: error: initializer element is not constant
/home/dac/test/openshell/shellparser.c:288: error: (near initialization for 'yyRuleName[0]')
/home/dac/test/openshell/shellparser.c: In function 'yy_destructor':
/home/dac/test/openshell/shellparser.c:370: error: expected expression before '%' token
/home/dac/test/openshell/shellparser.c:370: warning: statement with no effect
/home/dac/test/openshell/shellparser.c: In function 'yyStackOverflow':
/home/dac/test/openshell/shellparser.c:551: error: expected expression before '%' token
/home/dac/test/openshell/shellparser.c:551: warning: statement with no effect
/home/dac/test/openshell/shellparser.c: At top level:
/home/dac/test/openshell/shellparser.c:609: error: expected expression before '%' token
/home/dac/test/openshell/shellparser.c:609: warning: missing braces around initializer
/home/dac/test/openshell/shellparser.c:609: warning: (near initialization for 'yyRuleInfo[0]')
/home/dac/test/openshell/shellparser.c:609: error: initializer element is not constant
/home/dac/test/openshell/shellparser.c:609: error: (near initialization for 'yyRuleInfo[0].lhs')
/home/dac/test/openshell/shellparser.c: In function 'yy_reduce':
/home/dac/test/openshell/shellparser.c:664: error: expected expression before '%' token
/home/dac/test/openshell/shellparser.c:664: warning: statement with no effect
/home/dac/test/openshell/shellparser.c: In function 'yy_parse_failed':
/home/dac/test/openshell/shellparser.c:710: error: expected expression before '%' token
/home/dac/test/openshell/shellparser.c:710: warning: statement with no effect
/home/dac/test/openshell/shellparser.c: In function 'yy_syntax_error':
/home/dac/test/openshell/shellparser.c:726: error: expected expression before '%' token
/home/dac/test/openshell/shellparser.c:726: warning: statement with no effect
/home/dac/test/openshell/shellparser.c: In function 'yy_accept':
/home/dac/test/openshell/shellparser.c:745: error: expected expression before '%' token
/home/dac/test/openshell/shellparser.c:745: warning: statement with no effect
/home/dac/test/openshell/shellparser.c: At top level:
/home/dac/test/openshell/shellparser.c:918: error: expected identifier or '(' before string constant
/home/dac/test/openshell/shellparser.c:929: error: expected identifier or '(' before ',' token
Why is is happening and what can I do about it? Did I forget to include a library? My cmake file is
cmake_minimum_required(VERSION 3.0)
project(shell.test)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -L/usr/local/include/ -L/usr/include -std=c99 -pedantic -O3 -g -Wall -pedantic -ledit -lncurses -lcurses -ltermcap")
include_directories(/usr/local/include/ /usr/include)
link_directories(/usr/lib)
link_directories(/usr/local/lib)
add_executable(shell main.c shellparser.c errors.c util.c)
target_link_libraries(shell edit readline)
add_custom_target(shellparser DEPENDS ${CMAKE_SOURCE_DIR}/shellparser.c)
add_custom_command(OUTPUT ${CMAKE_SOURCE_DIR}/shellparser.c COMMAND lemon -s ${CMAKE_SOURCE_DIR}/shellparser.y DEPENDS ${CMAKE_SOURCE_DIR}/shellparser.y)
add_dependencies(shell shellparser)
set_property(TARGET shell PROPERTY C_STANDARD 99)$
On Ubuntu I can build it successfully:
$ git clone http://github.com/montao/openshell
Cloning into 'openshell'...
remote: Counting objects: 1439, done.
remote: Compressing objects: 100% (184/184), done.
remote: Total 1439 (delta 124), reused 0 (delta 0), pack-reused 1255
Receiving objects: 100% (1439/1439), 405.08 KiB | 117.00 KiB/s, done.
Resolving deltas: 100% (973/973), done.
Checking connectivity... done.
dac#dac-Latitude-E7450:~/montao/test$ cd openshell/
dac#dac-Latitude-E7450:~/montao/test/openshell$ mkdir build
dac#dac-Latitude-E7450:~/montao/test/openshell$ cd build/
dac#dac-Latitude-E7450:~/montao/test/openshell/build$ cmake ..
-- The C compiler identification is GNU 5.3.1
-- The CXX compiler identification is GNU 5.3.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/dac/montao/test/openshell/build
dac#dac-Latitude-E7450:~/montao/test/openshell/build$ make
Scanning dependencies of target shellparser
[ 14%] Generating ../shellparser.c
Parser statistics:
terminal symbols................... 9
non-terminal symbols............... 3
total symbols...................... 12
rules.............................. 8
states............................. 14
conflicts.......................... 0
action table entries............... 32
total table size (bytes)........... 100
[ 14%] Built target shellparser
Scanning dependencies of target shell
[ 28%] Building C object CMakeFiles/shell.dir/main.c.o
/home/dac/montao/test/openshell/main.c: In function ‘free_pipeline’:
/home/dac/montao/test/openshell/main.c:337:6: note: the ABI of passing struct with a flexible array member has changed in GCC 4.4
void free_pipeline(struct pipeline pipe) {
^
[ 42%] Building C object CMakeFiles/shell.dir/shellparser.c.o
[ 57%] Building C object CMakeFiles/shell.dir/errors.c.o
[ 71%] Building C object CMakeFiles/shell.dir/util.c.o
/home/dac/montao/test/openshell/util.c: In function ‘make_args’:
/home/dac/montao/test/openshell/util.c:1100:52: warning: operation on ‘jc’ may be undefined [-Wsequence-point]
char *str = concat((char *) *retArgv[jc++], (char *) *retArgv[jc]);
^
/home/dac/montao/test/openshell/util.c:1100:19: warning: unused variable ‘str’ [-Wunused-variable]
char *str = concat((char *) *retArgv[jc++], (char *) *retArgv[jc]);
^
[ 85%] Linking C executable shell
[100%] Built target shell
No matter what I do, the error is there when I compile with OpenBSD. I tried everything.

I haven't used OpenBSD but this could be caused by an "ancient" GCC 4.2.1 which was released 18 July 2007. On Ubuntu it's compiled with more recent GCC.
In fact if you check dependencies of project you want to build
Dependencies: editline, ncurses, C99
And C99 support in gcc
C99 is substantially completely supported as of GCC 4.5 (with -std=c99 -pedantic-errors used; -fextended-identifiers also needed to enable extended identifiers before GCC 5)

I can compile it like this with OpenBSD 5.9
gcc -std=c99 shellparser.c main.c util.c errors.c -ledit -ltermcap
IF I first generate the shellparser.c with Linux and copy the file to OpenBSD, then the above works to build for OpenBSD. But I still can't generate the C from the grammar with OpenBSD, there comes a compilation error. I can recreate the compilation error on Ubuntu and I'm still looking for what causes the diff in the generated C when I run lemon shellparser.y

Related

"error: implicitly declaring library function 'exit' with type" when configuring NetCDF on Mac

I need to compile the following project on a mac: cost733clas-1.4_rev23.tgz (download link)
The problem is, I have never worked with fortran or C and for the most part just worked with IDE's which took care of everything ...
Using the project guide I found out, that I need a fortran90 and a C compiler. Compilation using gcc worked up to a point, but at some point it fails on a sub-package/dependency (netcdf).
...
checking nm flags...
checking for C-equivalent to Fortran routine "SUB"... sub_
checking for Fortran "byte"... yes
checking for Fortran "integer*2"... yes
checking if Fortran "byte" is C "signed char"... configure: error: Could not compile conftest.c
configure: error: ./configure failed for netcdf-4.0.1
content of config.log:
configure:25351: gfortran -c -g -O2 conftest.f
configure:25354: $? = 0
configure:25356: result: yes
configure:25374: checking for Fortran "integer*2"
configure:25382: gfortran -c -g -O2 conftest.f
configure:25385: $? = 0
configure:25387: result: yes
configure:25414: checking if Fortran "byte" is C "signed char"
configure:25424: gcc -c -g -O2 conftest.c
conftest.c:4:3: error: implicitly declaring library function 'exit' with type 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-declaration]
exit(values[1] != -2 || values[2] != -3);
^
conftest.c:4:3: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit'
1 error generated.
configure:25427: $? = 1
configure:25468: error: Could not compile conftest.c
Does anyone have any suggestions on what compiler I should try/what flags I should use? (and how to set them)
the solution to my problem was to use linux instead of mac, i'm not quite sure what went wrong on mac, but creating a virutal linux machine and doing the same there works just fine.
for people who want to create a virtual machine some useful links:
https://www.virtualbox.org/wiki/Downloads
https://askubuntu.com/questions/413594/what-does-no-bootable-medium-found-mean-in-virtualbox
https://www.osboxes.org/ubuntu/#ubuntu-21-04-info
https://www.how2shout.com/linux/how-to-install-brew-ubuntu-20-04-lts-linux/

CMake Produces Makefile that Linker Doesn't Like

I'm trying to modernize a build system with CMake. When I try to compile the program with make I get this output
$ cmake -DCMAKE_TOOLCHAIN_FILE="../armgcc.cmake" .. && make
-- The C compiler identification is GNU 9.2.1
-- The CXX compiler identification is GNU 9.2.1
-- Check for working C compiler: /usr/bin/arm-none-eabi-gcc
-- Check for working C compiler: /usr/bin/arm-none-eabi-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/arm-none-eabi-g++
-- Check for working CXX compiler: /usr/bin/arm-none-eabi-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: ~/cmake_test/build
Scanning dependencies of target testproj
[ 50%] Building C object CMakeFiles/testproj.dir/main.c.obj
[100%] Linking C executable testproj
arm-none-eabi-gcc: fatal error: /usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/lib/nosys.specs: attempt to rename spec 'link_gcc_c_sequence' to already defined spec 'nosys_link_gcc_c_sequence'
compilation terminated.
make[2]: *** [CMakeFiles/testproj.dir/build.make:84: testproj] Error 1
make[1]: *** [CMakeFiles/Makefile2:76: CMakeFiles/testproj.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
With CMakeLists.txt
cmake_minimum_required(VERSION 3.0.0)
project(testproj VERSION 0.1.0)
add_executable(testproj main.c)
and armgcc.cmake
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_C_COMPILER arm-none-eabi-gcc)
set(CMAKE_CXX_COMPILER arm-none-eabi-g++)
set(CMAKE_ASM_COMPILER arm-none-eabi-gcc)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} --specs=nosys.specs")
What are link_gcc_sequence and nosys_link_gcc_sequence, and how should I structure my CMakeLists to avoid renaming them?

Setup google test with Mingw64 on windows 10 (C language)

I'm using Google test to test C code on Windows, but some problems happen when I do that. I have already installed Cmake, MingW64, python and set path for installed packages within Environment Variablest.Then I download https://github.com/google/googletest example and follow the guildline to run it.
The steps like this:
1. Open cmd on windows
2. cd xxx/googletest-master/googletest
3. cmake -G "MinGW Makefiles" CMakeLists.txt
The result like this:
C:\Users\TIEN\Desktop\UNITTEST\googletest-master\googletest>cmake -G "MinGW Makefiles" CMakeLists.txt
CMake Warning at CMakeLists.txt:54 (project):
VERSION keyword not followed by a value or was followed by a value that
expanded to nothing.
-- The CXX compiler identification is GNU 4.9.2
-- The C compiler identification is GNU 4.9.2
-- Check for working CXX compiler: C:/Program Files (x86)/Dev-Cpp/MinGW64/bin/g++.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Dev-Cpp/MinGW64/bin/g++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: C:/Program Files (x86)/Dev-Cpp/MinGW64/bin/gcc.exe
-- Check for working C compiler: C:/Program Files (x86)/Dev-Cpp/MinGW64/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found PythonInterp: C:/Program Files (x86)/Dev-Cpp/MinGW64/bin/python.exe (found version "2.7.8")
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/TIEN/Desktop/UNITTEST/googletest-master/googletest
4. mingw32-make.exe
The result like this:
C:\Users\TIEN\Desktop\UNITTEST\googletest-master\googletest>mingw32-make.exe
Scanning dependencies of target gtest
[ 25%] Building CXX object CMakeFiles/gtest.dir/src/gtest-all.cc.obj
In file included from C:/PROGRA~2/Dev-Cpp/MinGW64/lib/gcc/x86_64-w64-mingw32/4.9.2/include/c++/type_traits:35:0,
from C:/Users/TIEN/Desktop/UNITTEST/googletest-master/googletest/include/gtest/gtest.h:59,
from C:\Users\TIEN\Desktop\UNITTEST\googletest-master\googletest\src\gtest-all.cc:38:
C:/PROGRA~2/Dev-Cpp/MinGW64/lib/gcc/x86_64-w64-mingw32/4.9.2/include/c++/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
In file included from C:/Users/TIEN/Desktop/UNITTEST/googletest-master/googletest/include/gtest/internal/gtest-internal.h:40:0,
from C:/Users/TIEN/Desktop/UNITTEST/googletest-master/googletest/include/gtest/gtest.h:62,
from C:\Users\TIEN\Desktop\UNITTEST\googletest-master\googletest\src\gtest-all.cc:38:
C:/Users/TIEN/Desktop/UNITTEST/googletest-master/googletest/include/gtest/internal/gtest-port.h:972:1: error: identifier 'nullptr' is a keyword in C++11 [-Werror=c++0x-compat]
inline void FlushInfoLog() { fflush(nullptr); }
^
C:/Users/TIEN/Desktop/UNITTEST/googletest-master/googletest/include/gtest/internal/gtest-port.h:2104:1: error: identifier 'constexpr' is a keyword in C++11 [-Werror=c++0x-compat]
constexpr BiggestInt kMaxBiggestInt = (std::numeric_limits<BiggestInt>::max)();
^
In file included from C:/Users/TIEN/Desktop/UNITTEST/googletest-master/googletest/include/gtest/gtest.h:62:0,
from C:\Users\TIEN\Desktop\UNITTEST\googletest-master\googletest\src\gtest-all.cc:38:
........................................................
........................................................
C:/Users/TIEN/Desktop/UNITTEST/googletest-master/googletest/src/gtest.cc: At global scope:
C:/Users/TIEN/Desktop/UNITTEST/googletest-master/googletest/src/gtest.cc:189:14: error: 'FILE* testing::internal::OpenFileForWriting(const string&)' defined but not used [-Werror=unused-function]
static FILE* OpenFileForWriting(const std::string& output_file) {
^
C:/Users/TIEN/Desktop/UNITTEST/googletest-master/googletest/src/gtest.cc:357:13: error: 'bool testing::internal::GTestIsInitialized()' defined but not used [-Werror=unused-function]
static bool GTestIsInitialized() { return GetArgvs().size() > 0; }
^
cc1plus.exe: all warnings being treated as errors
CMakeFiles\gtest.dir\build.make:62: recipe for target 'CMakeFiles/gtest.dir/src/gtest-all.cc.obj' failed
mingw32-make.exe[2]: *** [CMakeFiles/gtest.dir/src/gtest-all.cc.obj] Error 1
CMakeFiles\Makefile2:76: recipe for target 'CMakeFiles/gtest.dir/all' failed
mingw32-make.exe[1]: *** [CMakeFiles/gtest.dir/all] Error 2
Makefile:82: recipe for target 'all' failed
mingw32-make.exe: *** [all] Error 2
It happen errors and can not run google test, How can I fix this issue ?

different ways of compilation cause the same dynamic library generate differents results

I use different ways of compilation to compile my project for testing symbol of a same cover when loaded dynamic library, however, there are two different results in different compilations, I cannot find differences between this two compilations, please help?
when I use dlopen() and dlsym(), I see official description of dlsym() as below:
The dlsym() function shall search for the named symbol in all objects
loaded automatically as a result of loading the object referenced by
handle (see dlopen()). Load ordering is used in dlsym() operations
upon the global symbol object. The symbol resolution algorithm used
shall be dependency order as described in dlopen().
Note: load ordering is an mechanism to handle conflict when loaded symbols with same name.
So I want to run a test for load ordering, however, I find different results when use different compilations(as I think two of them are equivalent)
here is my project:
file tree:
├── CMakeLists.txt
├── fn.c
└── main.c
CMakeLists.txt
project(demo)
set(CMAKE_CXX_FLAGS " -fpic ${CMAKE_CXX_FLAGS}")
add_library(fn SHARED fn.c)
add_executable(demo main.c)
target_link_libraries(demo -ldl)
fn.c
#include<stdio.h>
int temp = 1;
void fn_print(){
printf("fn temp address is %p, value is %d\n", &temp, temp);
}
main.c
#include<stdio.h>
#include<dlfcn.h>
typedef void (*fn_p)();
int temp = 0;
int main(){
printf("main temp address is %p, value is %d\n", &temp, temp);
void *handle = dlopen("./libfn.so", RTLD_NOW);
fn_p dy_print = dlsym(handle, "fn_print");
dy_print();
return 0;
}
First, I use cmake to compile this project and test, we can see variable temp share the same address 0x60104c and value 0 in obj file and dynamic library.
root#acnszavl00033:~/temp/dylib_test# cmake .
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /root/temp/dylib_test
root#acnszavl00033:~/temp/dylib_test# make
Scanning dependencies of target demo
[ 25%] Building C object CMakeFiles/demo.dir/main.c.o
[ 50%] Linking C executable demo
[ 50%] Built target demo
Scanning dependencies of target fn
[ 75%] Building C object CMakeFiles/fn.dir/fn.c.o
[100%] Linking C shared library libfn.so
[100%] Built target fn
root#acnszavl00033:~/temp/dylib_test# ./demo
main temp address is 0x60104c, value is 0
fn temp address is 0x60104c, value is 0
according to description, varaible temp should have different addresses, then I use gcc to only recompile demo(don't make changes to dynamic library libfn.so) , then test, varaible temp have different addresses, why?
root#acnszavl00033:~/temp/dylib_test# gcc -o demo main.c -ldl
root#acnszavl00033:~/temp/dylib_test# ./demo
main temp address is 0x60104c, value is 0
fn temp address is 0x7f795cec0028, value is 1
I expect output of compilatoin using cmake should like this:
main temp address is 0x60104c, value is 0
fn temp address is 0x7f795cec0028, value is 1
The below CMakeLists.txt seems to solve the issue:
cmake_minimum_required(VERSION 3.4)
project(demo)
add_library(fn SHARED fn.c)
add_executable(demo main.c)
target_link_libraries(demo PRIVATE dl)
When you don't add cmake_minimum_required or just provide anything below VERSION 3.4, you have the problem. Otherwise, when you build and run, you get the following:
~/so/build> cmake ..
-- The C compiler identification is GNU 9.1.0
-- The CXX compiler identification is GNU 9.1.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/aytekin/so/build
~/so/build> cmake --build .
Scanning dependencies of target fn
[ 25%] Building C object CMakeFiles/fn.dir/fn.c.o
[ 50%] Linking C shared library libfn.so
[ 50%] Built target fn
Scanning dependencies of target demo
[ 75%] Building C object CMakeFiles/demo.dir/main.c.o
[100%] Linking C executable demo
[100%] Built target demo
~/so/build> ./demo
main temp address is 0x56135a414044, value is 0
fn temp address is 0x7f170b3cb028, value is 1
I am not sure if this has to do with the policy change introduced in v3.4, but the most relevant change seems to be CMP0065.

building portmidi

I've been tring to build portmidi on OSX 10.8.2
http://sourceforge.net/apps/trac/portmedia/wiki/Installing%20portmidi%20on%20Mac
Anyway, the README tells me to first use the command:
make -f pm_mac/Makefile.osx
but bash returns the following error message:
[~/Desktop/portmedia/portmidi]
DanMoore -> make -f pm_mac/Makefile.osx
rm -f CMakeCache.txt
mkdir -p Release
cd Release; cmake .. -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release
-- The C compiler identification is GNU 4.2.1
-- The CXX compiler identification is Clang 4.0.0
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- SYSROOT: /Developer/SDKs/MacOSX10.5.sdk
-- DEFAULT_DEBUG_FLAGS not nil: -g
-- SYSROOT: /Developer/SDKs/MacOSX10.5.sdk
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/DanMoore/Desktop/portmedia/portmidi/Release
cd Release; make
Scanning dependencies of target pmjni
[ 3%] Building C object pm_common/CMakeFiles/pmjni.dir/__/pm_mac/pmmacosxcm.c.o
llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory
lipo: can't figure out the architecture type of: /var/folders/y4/p_kjk8692z73xy4nhwx6h_100000gn/T//cc73yejt.out
make[3]: *** [pm_common/CMakeFiles/pmjni.dir/__/pm_mac/pmmacosxcm.c.o] Error 255
make[2]: *** [pm_common/CMakeFiles/pmjni.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [all] Error 2
I wasn't expecting an easy build, but these errors look foreign to me.
Can anyone explain whats going on??
I'm trying to render a library file for simple C programs. (.a or .la)
Thanks in advance to anyone who takes a look!!

Resources