Recently I took it upon myself to see if I could get devd from the FreeBSD project to build and run on OpenBSD. In doing so, I found that the application itself was not fairly large, so it was not too much work to go through and find what I needed to do in order to make up for the missing system calls. All was well and good. However, it did not seem to link. Except for a few things relating to configuration files which I deemed seemingly discardable within this context, the Makefile of the project is exactly that which is present in the directory in the FreeBSD source. I have seen this kind of this happen with yacc before, but I do not have the knowledge necessary to know how to resolve this. This is seemingly the only thing preventing me from testing it at this point.
Well, there was one include in the Makefile which was FreeBSD specific. I commented it out to see what that would do. It appeared to me that the include was necessary for a conditional statement about configuration files to theoretically be used by the daemon after it is already in production. Nothing to do fundamentally with the build process. After that, I did what any person trying to port software would do - I began the compilation process and started looking at all of the errors that the compiler was shooting back at me, and seeing if I could refactor it to work with the system being ported to. That part work fairly well, and I was able to eliminate all compiler errors and warning. I was expecting the Makefile provided would be sufficient to build the application for me.
Here is the error I was left with:
foo$ make devd
c++ -O2 -pipe -MD -MP -o devd devd.cc
ld: error: undefined symbol: yyin
>>> referenced by devd.cc
>>> /tmp/devd-e407ee.o:(config::parse_one_file(char const*))
ld: error: undefined symbol: lineno
>>> referenced by devd.cc
>>> /tmp/devd-e407ee.o:(config::parse_one_file(char const*))
>>> referenced by devd.cc
>>> /tmp/devd-e407ee.o:(new_match)
ld: error: undefined symbol: yyparse
>>> referenced by devd.cc
>>> /tmp/devd-e407ee.o:(config::parse_one_file(char const*))
ld: error: undefined symbol: pidfilefoo$ make devd
c++ -O2 -pipe -MD -MP -o devd devd.cc
ld: error: undefined symbol: yyin
>>> referenced by devd.cc
>>> /tmp/devd-e407ee.o:(config::parse_one_file(char const*))
ld: error: undefined symbol: lineno
>>> referenced by devd.cc
>>> /tmp/devd-e407ee.o:(config::parse_one_file(char const*))
>>> referenced by devd.cc
>>> /tmp/devd-e407ee.o:(new_match)
ld: error: undefined symbol: yyparse
>>> referenced by devd.cc
>>> /tmp/devd-e407ee.o:(config::parse_one_file(char const*))
ld: error: undefined symbol: pidfile
>>> referenced by devd.cc
>>> /tmp/devd-e407ee.o:(config::open_pidfile())
>>> referenced by devd.cc
>>> /tmp/devd-e407ee.o:(main)
>>> referenced by devd.cc
>>> /tmp/devd-e407ee.o:(main)
c++: error: linker command failed with exit code 1 (use -v to see invocation)
>>> referenced by devd.cc
>>> /tmp/devd-e407ee.o:(config::open_pidfile())
>>> referenced by devd.cc
>>> /tmp/devd-e407ee.o:(main)
>>> referenced by devd.cc
>>> /tmp/devd-e407ee.o:(main)
c++: error: linker command failed with exit code 1 (use -v to see invocation)
And here is the BSD-style Makefile I was using to attempt to build this
# $FreeBSD$
#.include <src.opts.mk>
WARNS?= 3
PACKAGE=devd
CONFGROUPS= CONFS DEVD
CONFS= devd.conf
DEVD= devmatch.conf
DEVDDIR= /etc/devd
#.if ${MK_ACPI} != "no"
#DEVD+= asus.conf
#.endif
#.if ${MK_HYPERV} != "no"
#CONFGROUPS+= HYPERV
#HYPERVDIR=${DEVDDIR}
#HYPERV+= hyperv.conf
#HYPERVPACKAGE= hyperv-tools
#.endif
#.if ${MK_USB} != "no"
#DEVD+= uath.conf ulpt.conf
#.endif
#.if ${MACHINE_ARCH} == "powerpc"
#DEVD+= apple.conf
#.endif
#.if ${MK_ZFS} != "no"
#DEVD+= zfs.conf
#.endif
PROG_CXX=devd
SRCS= devd.cc token.l parse.y y.tab.h
MAN= devd.8 devd.conf.5
LIBADD= util
YFLAGS+=-v
CFLAGS+=-I. -I${.CURDIR}
CFLAGS.clang += -Wno-missing-variable-declarations
CFLAGS.gcc = -Wno-redundant-decls
CXXFLAGS.gcc = -Wno-redundant-decls
CLEANFILES= y.output y.tab.i
HAS_TESTS=
SUBDIR.${MK_TESTS}+= tests
.include <bsd.prog.mk>
You can find the project's source on GitHub here
Thank you all very much in advance for your time, attention, effort, and thoughtful answers. Community is important! 🙂
Since I knew that the system binary 'config' in the '/sbin' directory of the OpenBSD source tree also uses YACC, I decided that I would try simple making a very simple replicate Makefile out of the useful information gained from that Makefile. That proved successful in this case...
.include <bsd.own.mk>
PROG= devd
SRCS= devd.cc parse.y token.l
DPADD += ${LIBUTIL}
LDADD += -lutil
MAN= devd.8 devd.conf.5
.include <bsd.prog.mk>
As one can see, it is relatively short, simple, sweet, and straight to the point. It did not require much at all to be successful. However, I think the problem here simply lied in the slight difference in the 'make' systems between FreeBSD and OpenBSD. In any case, this build, and the pidfile handling should be all squared away, in line with the OpenBSD process. All other systems call conflicts have been resolved. Now all that is left to do with is is install and test! 🙂
Related
When using macOS's built in ld, I get the following error:
ld -arch x86_64 -platform_version macos 11.0 12.2.1 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -lSystem -lc++ -o /Users/blashyrk/Documents/source/nim/asserttrigger /Users/blashyrk/.cache/nim/asserttrigger_d/asserttrigger.o
Undefined symbols for architecture x86_64:
"_nlvmEHPersonality", referenced from:
Dwarf Exception Unwind Info (__eh_frame) in asserttrigger.o
ld: symbol(s) not found for architecture x86_64
However, that symbol is a function that's defined inside that very same object file.
Using objdump on the object file, I can confirm that the function is indeed there:
objdump -t ~/.cache/nim/asserttrigger_d/asserttrigger.o | grep nlvmEH
00000000000063b0 l F __TEXT,__text _nlvmEHPersonality
And just to make sure I wasn't crazy, I decided to see for myself with Ghidra (please see attached image).
So my question is, what makes macOS's ld not find this symbol? When using LLVM's lld it works, so the symbol is defined properly.
Am I, perhaps, missing a flag? Is ld expecting the EH personality function to be a part of some external object/library?
Here's also a link to the object file, if someone wants to try it out on their end: https://www46.zippyshare.com/v/0UFxM7zD/file.html
The program (if you manage to link it successfully) should run and exit with no output.
I've gotten it to work by changing the linkage type of nlvmEHPersonality from internal to external.
For some reason, ld64 cant't find it with internal linkage even though lld can.
I am currently trying to make and install a specialist suite of software (https://github.com/scottransom/presto), and am encountering this error:
gfortran -g -fPIC -o /path-to/presto/bin/psrorbit powerplot.o xyline.o psrorbit.o -L/usr/local/Cellar/cfitsio/3.450/lib -lcfitsio -lcurl -L/path-to/presto/lib -lpresto -L/usr/local/lib -lfftw3f -L/usr/local/lib/pgplot -lcpgplot -lpgplot -L/opt/X11/lib -lX11 -L/opt/X11/lib -lpng16 -lm
ld: mach-o string pool extends beyond end of file in /usr/local/lib/libcpgplot.dylib file '/usr/local/lib/libcpgplot.dylib' for architecture x86_64
collect2: error: ld returned 1 exit status
make: *** [psrorbit] Error 1
I don't think it's a problem related to PRESTO per se, as several searches (see this, this, and this) point to something fundamental, perhaps with Xcode. I currently have version 11.3, and I also installed the command line tools. So again, what does the error itself mean? Any help would be useful!
According to my reading of the source code for Apple's version of ld, this error means that the symbol table in an object prematurely ends when the file does.
There appear to be quite a few sanity checks performed on object files when linking. Likely, your copy of /usr/local/lib/libcpgplot.dylib is corrupt.
I'm trying to Compile a Mex file, this example, in MATLAB that uses the CPLEX API in C to solve linear programming problems. Unfortunately, I get this error :
mex - I/..../Applications/IBM/ILOG/CPLEX_Studio1271/cplex/include/ilcplex -
L/...../Applications/IBM/ILOG/CPLEX_Studio1271/cplex/lib/x86-
64_osx/static_pic -lcplex lp_cplex_mex.c
Building with 'Xcode with Clang'.
/..../Desktop/example/lp_cplex_mex.c:142:9: warning: implicit
declaration of function 'CPXopenCPLEXdevelop' is invalid in C99 [-
Wimplicit-function-declaration]
env = CPXopenCPLEXdevelop(&status);
^
/....../Desktop/example/lp_cplex_mex.c:142:7: warning: incompatible
integer to pointer conversion assigning to 'CPXENVptr' (aka 'struct
cpxenv *') from 'int' [-Wint-conversion] env =
CPXopenCPLEXdevelop(&status);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/......./Desktop/example/lp_cplex_mex.c:209:20: warning: implicit
declaration of function 'CPXgetitc' is invalid in C99 [-Wimplicit-
function-declaration] *itcnt = (double)CPXgetitc(env,lp);
^
3 warnings generated.
Error using mex
Undefined symbols for architecture x86_64:
"_CPXgetitc", referenced from:
_mexFunction in lp_cplex_mex.o
(maybe you meant: _CPXgetitcnt)
"_CPXopenCPLEXdevelop", referenced from:
_mexFunction in lp_cplex_mex.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
Some basic information:
I can compile yprime.c and other MEX files that do not use the CPLEX
API
I am using MATLAB 2015a on Mac OSX El Capitan 10.11.16
I am using the GCC package included in XCode 8.2
I guess my problem is with library, it can find the folder but something wrong inside, There is the content of .../cplex/lib/x86-64_osx/static_pic file:
libilocplex.a
libcplexdistmip.a
libcplex.a
I think we should have files with .so extension, I would greatly appreciate any advice people may have.
I am following this guide on how to build a project using GLFW3 with CMake on OSX 10.9.1, and I've run into some trouble. When I get to building the actual project I get the following errors:
$ make
Scanning dependencies of target Graphics
[100%] Building CXX object CMakeFiles/Graphics.dir/graphics.cpp.o
Linking CXX executable Graphics
Undefined symbols for architecture x86_64:
"_glBegin", referenced from:
_main in graphics.cpp.o
"_glClear", referenced from:
_main in graphics.cpp.o
"_glColor3f", referenced from:
_main in graphics.cpp.o
"_glEnd", referenced from:
_main in graphics.cpp.o
"_glLoadIdentity", referenced from:
_main in graphics.cpp.o
"_glMatrixMode", referenced from:
_main in graphics.cpp.o
"_glOrtho", referenced from:
_main in graphics.cpp.o
"_glRotatef", referenced from:
_main in graphics.cpp.o
"_glVertex3f", referenced from:
_main in graphics.cpp.o
"_glViewport", referenced from:
_main in graphics.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [Graphics] Error 1
make[1]: *** [CMakeFiles/Graphics.dir/all] Error 2
make: *** [all] Error 2
My CMakeLists.txt looks like:
cmake_minimum_required (VERSION 2.8)
project (Graphics)
# The version number.
set (Graphics_VERSION_MAJOR 1)
set (Graphics_VERSION_MINOR 0)
# configure a header file to pass some of the CMake settings
# to the source code
configure_file (
"${PROJECT_SOURCE_DIR}/GraphicsConfig.h.in"
"${PROJECT_BINARY_DIR}/GraphicsConfig.h"
)
# add the binary tree to the search path for include files
# so that we will find GraphicsConfig.h
include_directories("${PROJECT_BINARY_DIR}")
find_package(PkgConfig REQUIRED)
pkg_search_module(GLFW REQUIRED glfw3)
include_directories(${GLFW_INCLUDE_DIRS})
# add the executable
add_executable (Graphics graphics.cpp)
target_link_libraries(Graphics ${GLFW_STATIC_LIBRARIES})
# add the install targets
install (TARGETS Graphics DESTINATION bin)
install (FILES "${PROJECT_BINARY_DIR}/GraphicsConfig.h"
DESTINATION include)
However can build the project just fine using
cc `pkg-config --cflags glfw3` -o graphics graphics.cpp \
`pkg-config --static --libs glfw3`
I can't offer you an explanation for why one links with the OpenGL libs and the other doesn't, but the following solution worked for me with a similar problem on OSX (Mountain Lion).
At the end of the 'add executable' block, add an Apple-specific condition to link with the OpenGL framework:
# add the executable
add_executable (Graphics graphics.cpp)
target_link_libraries(Graphics ${GLFW_STATIC_LIBRARIES})
if (APPLE)
target_link_libraries(Graphics "-framework OpenGL")
endif()
I figured there must be something in the GLFW CMake config that was responsible for linking with the OpenGL libs so I had a look at the GLFW 3.0.4 CMakeLists.txt and found that '-framework' line.
This will only help you on OSX - you'd need to supply other platform specific ways of linking to make it cross platform.
You may have already considered it, but the same guide also provides a way to include the GLFW source with your app and build it that way. That's probably the easiest way to guarantee cross-platform compatibility.
I had to do this.
elseif(APPLE)
# GLFW
find_package(glfw3 REQUIRED)
include_directories(${GLFW_INCLUDE_DIRS})
find_package(GLEW REQUIRED)
include_directories(${GLEW_INCLUDE_DIRS})
# app_framework executable
add_executable(app_framework ${SOURCE_FILES})
target_link_libraries(app_framework app_framework_library ${GLEW_LIBRARY} glfw3)
target_link_libraries(app_framework "-framework OpenGL")
Note that I use "glfw3" instead of ${GLFW_STATIC_LIBRARIES} in target_link_library. Did not work for me otherwise.
I'm using cmake 3.6.1.
Add this to your CMakeFile,
add_executable(${LOCAL_PROJECT_NAME} )
#openGL Specific
target_link_libraries(${LOCAL_PROJECT_NAME} ${GLFW_STATIC_LIBRARIES})
find_package(glfw3 3.3 REQUIRED)
target_link_libraries(${LOCAL_PROJECT_NAME} glfw)
find_package(OpenGL REQUIRED)
target_link_libraries(${LOCAL_PROJECT_NAME} OpenGL::GL)
also, make sure compiler options are set accordingly.
Hi, I am using Xcode 4 and trying to set up FLTK 1.3.0 to run Bjarne
Stroustrup's Chapter 12 FLTK Demo at the end of the chapter. I keep
getting the following error when compiling, and have no idea where to go.
I have an idea it might have to do with the linker flags, but I don't know
what flag to add and where...
Here's the error:
Undefined symbols for architecture x86_64:
"Fl_JPEG_Image::Fl_JPEG_Image(char const*)", referenced from:
Graph_lib::Image::Image(Point, String,
Graph_lib::Suffix::Encoding) in Graph.o
"Fl_GIF_Image::Fl_GIF_Image(char const*)", referenced from:
Graph_lib::Image::Image(Point, String,
Graph_lib::Suffix::Encoding) in Graph.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
Are you passing the linker flags present with --use-images? try:
> fltk-config --use-images --ldflags
and check the results to make sure you're getting either the system image libs, or the ones optionally built with fltk.
I also found this to be quite useful:
fltk-config --compile test.cpp
It worked perfectly for me.
For more examples of using fltk-config check out http://www.fltk.org/doc-1.1/basics.html