So I'm working through an assignment for Stanford's CS107 course and I can't get past compiling the unfinished program (project files and the original makefile can be found on the course page, I'm working on assignment 4 RSS.)
After much research, I think the problem is I'm using gcc on a 64-bit architecture (Mac OS 10.6) and the pre-compiled library code under assn-4-rss-news-search-lib/linux is for a 32-bit architecture. I tried setting gcc to use i386 and -m36, but nothings working and I'm kind of just guessing.
So here's the output I get when I run make:
gcc -g -Wall -std=gnu99 -Wno-unused-function -c -o rss-news-search.o rss-news-search.c
gcc rss-news-search.o -g -Wall -std=gnu99 -Wno-unused-function -g -lnsl -lrssnews -L/Users/derp/Documents/OCW/CS107/Work/programming4/assn-4-rss-news-search-lib/linux -o rss-news-search
ld: library not found for -lnsl
collect2: ld returned 1 exit status
make: *** [rss-news-search] Error 1
Here's the output I get when I remove -lnsl where architecture differences are mentioned:
gcc -g -Wall -std=gnu99 -Wno-unused-function -c -o rss-news-search.o rss-news-search.c
gcc rss-news-search.o -g -Wall -std=gnu99 -Wno-unused-function -g -lrssnews -L/Users/derp/Documents/OCW/CS107/Work/programming4/assn-4-rss-news-search-lib/linux -o rss-news-search
ld: warning: in /Users/derp/Documents/OCW/CS107/Work/programming4/assn-4-rss-news-search-lib/linux/librssnews.a, file was built for unsupported file format which is not the architecture being linked (x86_64)
Undefined symbols:
"_URLConnectionDispose", referenced from:
_ProcessFeed in rss-news-search.o
_ParseArticle in rss-news-search.o
... several more undefined symbols mentioned ...
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [rss-news-search] Error 1
So I'm asking for any ideas on what I could do to resolve this. I've been at it for hours tweaking settings and Google'ing around to no avail.
In case someone like me will be looking for answer after all this time passed...
Problem is easy solved by installing wubi version of 32bit Ubuntu. It works fine on 64bit system. You only need to edit makefile so it knows where to look for the libraries provided.
I'm pretty sure that using a precompiled library for linux on macos, whatever the bitness, won't work (well, it is probably possible to cross-compile on MacOS for Linux and perhaps possible to run Linux executable in a compatibility box on MacOS, but that's quite different than what you are trying to do).
libnsl is a standard library on Linux (it provides some networking related functions)
Related
Problem with linking portaudio into an c program on Linux.
System: Linux Ubuntu 20.4 i5 16 GB
ALSA and pulseaudio were preinstralled.
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
gcc -Wall wm_1.c -lm libportaudio.a -o wm_1
The linker gives me more than 100 error messages all of type "undefined reference"
Here 2 examples out of >100
/home/max/Desktop/dev/portaudio/src/hostapi/alsa/pa_linux_alsa.c:504: undefined reference to snd_pcm_status_get_delay' /home/max/Desktop/dev/portaudio/src/hostapi/oss/pa_unix_oss.c:1778: undefined reference to __pthread_unregister_cancel'
So its obvious that the named parameter/function can not be found.
The error messages all point to source files in the source directory (the directory of the portaudio
package I downloaded to creatie the libs which were all created without error.
The libs are in /usr/local/..
libportaudio.a libportaudio.la libportaudio.so libportaudio.so.2 libportaudio.so.2.0.0 pkgconfig python3.8
and I copied libportaudio.a into the project directory. The lib has a a size of 1.1 MB .
if I use the dynamic libportaudio.so I get the error messages at run time.
I suspect that something went totally wrong with creating the libraries but I have no idea how to solve that
Other option:
Linking parameter or files missing ?
Header file ?
The same program compiles, links and runs without any problem on a iMac OS 10.13.6
where I used the dynamic lib .dylib.
gcc -v wm_1.c libportaudio.dylib -o wm_1
From the documentation:
Note that you will usually need to link with the approriate libraries that you used, such as ALSA and JACK, as well as with librt and libpthread. For example:
gcc main.c libportaudio.a -lrt -lm -lasound -ljack -pthread -o YOUR_BINARY
A little googling goes a long way...
This works:
gcc -Wall wm_1.c -lm libportaudio.a -lasound -pthread -o test.
gcc main.c libportaudio.a -lrt -lm -lasound -ljack -pthread -o YOUR_BINARY
I used that page and the command line at the begin using all 3 parameter but got errors, probably of misspelling, so I gave up on that (also because on the Mac OS it was not necessary). It now links without errors using -lasound and -pthread only (-pthread alone gives still errors and the use/not use of -ljack makes no difference).
I get some errors when I run the program but probably because of missing or wrong ALSA parameter settings. I found -pthread but I could not find -ljack and -lasound.
So the question: what are this 2 parameter doing?
It must be link parameter, but where is the documentation, I searched ld and gcc and did not find anything, while -pthread is documented.
I am trying to use a make file that my professor provided, but that make file is made to work in an Arch Linux VM, and not my Mac environment. To solve this, I've downloaded gmake and gcc via homebrew, and swapped them out as the make and compiler targets in my CLion toolchain. However, when I try to build, I am still getting the error "ld: unknown option: -rpath=$ORIGIN". This is the line that is failing (line 10) everytime:
$(CC) $(CFLAGS) $(LDFLAGS) -DDEBUG=$(DEBUG) -L. -Wl,-rpath='$$ORIGIN' -driverfile myfile.c -o $#
Here is my output when I hit build:
====================[ Build | all ]=============================================
/usr/local/Cellar/make/4.3/bin/gmake --jobs=9 all
/usr/local/Cellar/gcc/11.2.0_3/bin/gcc-11 -Wall -g -DDEBUG=1 -L. -Wl, -rpath='$ORIGIN' -driverfile myfile.c -o myfile
ld: unknown option: -rpath=$ORIGIN
collect2: error: ld returned 1 exit status
gmake: *** [Makefile:10: myfile] Error 1
I am allowed to modify the makefile for testing purposes on my local machine, so long as all the stuff still works with the original makefile on the Arch Linux VM, and I'm happy to do this if it's the only solution, but I'd much rather figure out why its not working as is. (Even if the answer is 'Bc its a Mac and Apple says so.')
I am not an experienced programmer/developer/software engineer, but I need to get this older version of guile-2.0.11 built "by hand" rather than using home-brew (which installs the latest version of guile). I downloaded the tarball for guile-2.0.11 from the GitHub repository, extracted it and ran the shell script autogen.sh. This produced a configure executable which ran to completion and generated a Makefile. When I run make, the build continues until I get the this error:
Undefined symbols for architecture x86_64:
"_clock_getcpuclockid", referenced from:
_scm_init_stime in libguile_2.0_la-stime.o
"_ffi_call", referenced from:
_scm_i_foreign_call in libguile_2.0_la-foreign.o
and 16 more "ffi" similar messages. Then the error messages finishes
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [libguile-2.0.la] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
The linker apparently can't find these symbols. The explicit link command is quite extensive..it shows all the options, include and library paths if I use "make V=1". Here is the beginning, showing the options and paths:
Applications/Xcode.app/Contents/Developer/usr/bin/make all-am
/bin/sh ../libtool --tag=CC --mode=link gcc - I/usr/local/opt/gettext/include -I/usr/local/include - I/usr/local/opt/readline/include - I/usr/local/Cellar/gettext/0.19.8.1/include -D_THREAD_SAFE -Wall - Wmissing-prototypes -Wdeclaration-after-statement -Wpointer-arith -Wswitch- enum -fno-strict-aliasing -fwrapv -fvisibility=hidden - I/usr/local/Cellar/bdw-gc/7.6.0/include -g -O2 -L/usr/local/Cellar/bdw- gc/7.6.0/lib -lgc -L/usr/local/opt/libffi/lib -liconv - L/usr/local/opt/gettext/lib -lintl -R/usr/local/opt/gettext/lib -Wl,- framework -Wl,CoreFoundation -L/usr/local/lib -lunistring -R/usr/local/lib -version-info 29:2:7 -export-dynamic -no-undefined -L/usr/local/opt/gettext/lib -L/usr/local/lib -L/usr/local/opt/readline/lib -L/usr/local/Cellar/gettext/0.19.8.1/lib -o libguile-2.0.la -rpath /usr/local/lib
Then there is libtool.
libtool: link: gcc -dynamiclib -o .libs/libguile-2.0.22.dylib .libs/libguile_2.0_la-alist.o .libs/libguile_2.0_la-arbiters.o .libs/libguile_2.0_la-array-handle.o
and many many more xxxx.o
then
-Wl,-force_load,../lib/.libs/libgnu.a -L/usr/local/Cellar/bdw- gc/7.6.0/lib -lgc -L/usr/local/opt/libffi/lib -L/usr/local/opt/gettext/lib -L/usr/local/lib -L/usr/local/opt/readline/lib - L/usr/local/Cellar/gettext/0.19.8.1/lib -lintl -lunistring -liconv -lgmp - lltdl -lm -g -O2 -Wl,-framework -Wl,CoreFoundation -install_name /usr/local/lib/libguile-2.0.22.dylib -compatibility_version 30 - current_version 30.2 -Wl,-single_module
The up-to-date version of ffilib is in the symlink /usr/local/opt/libffi/lib which is in the ld path, so I would think that the linker could find it. Any help would be greatly appreciated.
This problem is really two problems: (1) the undefined symbol "_clock_getcpuclockid" and (2) all the "ffi" undefined symbols. The answer to the second problem is here and the answer to the first problem is here. There may be other solutions but these resulted in the installation of guile-2.0.11 on my macOS Sierra (10.12.5),
I'm trying to compile and link some .c file. I have been using Eclipse IDE for C/C++ developers, and in my local machine i can compile without problems. However, when i try to compile and link the same file in a RedHat OS (gcc version is 4.9.2-6 in this OS) i'm having problems. I get some warnings at compile time, but those are fine, i think, i just ignored and the application still runs fine. Here are the commands i executed and the associated output:
gcc -O0 -g3 -Wall -c -fmessage-length=0 -std=c99 -MMD -MP -MF"example.d" -MT"example.d" -o "example.o" "example.c"
warning: suggest parentheses around assignment used as truth value [-Wparentheses]
warning: implicit declaration of function ‘wait’ [-Wimplicit-function-declaration]
This generates two files, example.d and example.o. Then, i try to link them, without luck, with the following command:
gcc -Xlinker -L/usr/lib -lrt -static -pthread example.o -o example
/usr/bin/ld: cannot find -lrt
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
The commands are taken directly from the ones that Eclipse generates, and work just fine in my local computer (Ubuntu OS) but not in the RedHat environment. The last command didn't work, with and without the -L option. I suppose the directory in -L is fine, as i run, for example,
locate libpthread.so
And one of the locations i get is /usr/lib (also /usr/lib64, but neither work).
Any help will be greatly appreciated!! :)
If you try to link a static executable, it will look for the *.a versions of the libraries, not what you usually want. Remove the -static flag. Or you can install the static libraries if you really want to. It also should not be necessary to add -L/usr/lib explicitly.
I'm trying to compile the NIF Test from Erlang (http://www.erlang.org/doc/man/erl_nif.html) on Mac OS X Lion. I can't get it to compile. Am I missing a compiler flag? Here's the error I get:
Computer:~ me $ gcc -fPIC -shared -o niftest.so niftest.c -I /usr/local/Cellar/erlang/R14B02/lib/erlang/usr/include/
Undefined symbols for architecture x86_64:
"_enif_make_string", referenced from:
_hello in ccXfh0oG.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
I've also tried this with -m32 but it says there's no i386 architecture either.
Thanks!
for 64-bit Erlang, the following works for me:
gcc -undefined dynamic_lookup -dynamiclib niftest.c -o niftest.so \
-I /usr/local/Cellar/erlang/R14B02/lib/erlang/usr/include
It seems like your problem is not architecture but undefined symbol _enif_make_string, which means that you have to link with your enif library, whatever it is, using -l option. Also, it's been a long time since I built a shared library for OS X, but I think that the right flag to use is -dynamiclib and not -shared, and you don't have to have a space after -I.
Try using these flags when compiling your nif instead of -shared
-bundle -flat_namespace -undefined suppress