Unable to link a static C library in an Obj-C project (Xcode 4.6.3) - objective-c

I'm trying to build a basic FTP client using libftp. I've compiled and archived it as libftp.a and placed it in /usr/local/lib. All the necessary headers I've placed in /usr/local/include/ftp.
Under Build Settings, I've set "Header Search Paths" to /usr/local/include, and I've set "Library Search Paths" to /usr/local/lib. For "Other Linker Flags", I've added -lftp.
Here is the shell of my C++ class:
Connector.h:
#include <stdlib.h>
#include <ftp/ftp.h>
#include <stdio.h>
class Connector{
private:
FtpConnection *connection;
public:
Connector();
~Connector();
bool connect(const char *hostname, const char *port);
};
Connector.cc:
#include "Connector.h"
Connector::Connector(){
}
Connector::~Connector(){
}
bool Connector::connect(const char *hostname, const char *port){
ftpGetAddresses(hostname, port);
printf("Connected!\n");
return true;
}
Upon compiling, this is the error I get:
Undefined symbols for architecture x86_64: "ftpGetAddresses(char
const*, char const*)", referenced from:
Connector::connect(char const*, char const*) in Connector.o ld: symbol(s) not found for architecture x86_64 clang: error: linker
command failed with exit code 1 (use -v to see invocation)
It's probably worth noting that this is part of a Cocoa project, so the Connector class is #included in my AppDelegate, which is of course an Obj-C class. All of my Obj-C source files have the .mm extension.
I am certain that the lib is in working order, as I have no issue compiling a program on the command line with gcc ... -lftp. It's only a problem with Xcode.

Well, it appears I just talked myself through my own problem. As I was typing the last part of my question, I realized that the issue was linking a C library in a C++ source file. gcc would compile just fine on command line, but g++ gave me the same error as Xcode. One google search later I found this link, which solved my problem beautifully. Basically, if you want a C library to be compatible with C++, you need to add
#ifdef __cplusplus
extern "C" {
#endif
at the top of the library header file, and add
#ifdef __cplusplus
}
#endif
at the bottom of the file. I'll leave the question here hoping it will help someone else in the future.

Related

Importing AppKit.h: function does not return NSString

I am using Nvim to try and develop a Mac application. I have just imported AppKit.h to instantiate a sharedApplication.
I am using coc-clangd for autocompletion. I am getting the following error when I import AppKit.h.
In included file: function does not return NSString
[clang: format_attribute_result_not]
The code:
#include <stdio.h>
#include <AppKit/AppKit.h>
int main(int argc, const char * argv[])
{
printf("Hello world");
return 0;
}
I should also mention that the code is compiling just fine. I have tried the following compile commands and both of them have worked.
clang -framework AppKit -o a osx_main.mm
clang -Wall -o a osx_main.mm
You should choose command line tool version,
Xcode ▶ Preferences ▶ Location ▶ Command Line Tool ▶
then choose appropriate command line tool version.

Issue with CMake when using glib library

I am writing a bluez C program to read battery service. I am using CMake for building the code.
My Cmake File is :
# CMakeLists file for module-bluez project
cmake_minimum_required(VERSION 3.02)
project (bluez-module)
find_package(PkgConfig REQUIRED)
# Adding dbus library
pkg_check_modules(DBUS REQUIRED dbus-1>= 1.6)
include_directories(${DBUS_INCLUDE_DIRS})
link_directories(${DBUS_LIBRARY_DIRS})
#Adding glib library
pkg_check_modules(GLIB REQUIRED glib-2.0>=2.23)
include_directories(${GLIB_INCLUDE_DIRS})
link_directories(${GLIB_LIBRARY_DIRS})
pkg_check_modules (DBUSGLIB REQUIRED dbus-glib-1)
include_directories(${DBUSGLIB_INCLUDE_DIRS})
link_directories(${DBUSGLIB_LIBRARY_DIRS})
# Adding bluetooth using extra libs
list(APPEND EXTRA_LIBS "bluetooth")
# Expose 'gattlib.h' to all sub-directories
include_directories(include)
add_executable(bluez-module scantest.c)
# Linking libraries
message(${DBUSGLIB_LIBRARIES})
target_link_libraries(bluez-module ${EXTRA_LIBS})
#target_link_libraries(bluez-module ${DBUS_LIBRARIES})
target_link_libraries(bluez-module ${DBUSGLIB_LIBRARIES})
target_link_libraries(bluez-module ${GLIB_LIBRARIES})
I have to use g_main_loop in my code. But after building the source file I always get the below error :
[ 50%] Linking C executable bluez-module
CMakeFiles/bluez-module.dir/scantest.c.o: In function `read_battery_service':
scantest.c:(.text+0x5b8): undefined reference to `g_dbus_setup_bus'
collect2: error: ld returned 1 exit status
My read_battery function code is as below :
int read_battery_service(struct hci_state *current_hci_state , char *dev_addr)
{
GError *error = NULL;
GDBusClient *client;
GOptionContext *context;
context = g_option_context_new(NULL);
main_loop = g_main_loop_new(NULL, FALSE);
dbus_conn = g_dbus_setup_bus(DBUS_BUS_SYSTEM, NULL, NULL);
return 0;
}
Just trying to initialize for to access dbus apis.
I have included these headers in the code
#include <assert.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>
#include <stdio.h>
#include <gdbus.h>
#include <glib/gmain.h>
What would be the issue ? Is glib.h contains the function g_main_loop_new ? Where should I find it ? Or Is CMake not linking glib properly ?
Looks like you are missing the gdbus linker flags. Try using
pkg_check_modules (DBUSGLIB REQUIRED dbus-glib-1) and add
target_link_libraries(module-bluez ${DBUS_LIBRARIES} ${DBUSGLIB_LIBRARIES})
and see if it helps.

Compiling object c (.m) file to an object file(.o) in osx

Thanks for reviewing the problem. There is an object c file called try.m, and I complie it to an object file try.o with the command:
gcc -c try.m -o try.o -framework Foundation
the try.h is
int print_word( void );
The try.m is:
#include "try.h"
#import <Foundation/Foundation.h>
int print_word( void )
{
NSLog (#"say hello");
return 0;
}
Additionly, there is a main.c file, which contain the main() function, and it looks:
#include <stdio.h>
#include "try.h"
int main()
{
printf( "This is main\n");
}
I compile main.c to main.o by the following command:
gcc -o main.o -c main.c
Then, I link the main.o and try.o to form the executable file main:
gcc -o main main.o try.o
After these steps, the following errors happened:
enter image description here
The errors are:
Undefined symbols for architecture x86_64:
"_NSLog", referenced from:
_print_word in try.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
How could these errors be solved?
You need to link against the Foundation framework. You can do it all in a single command: gcc main.c try.m -framework Foundation.

Linking to a static lib compiled with MSVC

I'm trying to link with a simple C lib on windows against Rust library
My lib is .h
extern "C" {
void say_hello(const char* s);
}
.cpp
#include <stdio.h>
void say_hello(const char* s) {
printf("hello world");
}
My Rust file
#[link(name="CDbax", kind="static")]
extern "C" {
fn say_hello(s: *const libc::c_char) -> () ;
}
Linking fails by giving an error with one of the data symbols
error: linking with `gcc` failed: exit code: 1
note: "gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-Wl,--large-address-aware" "-shared-libgcc" "-L" "C:\Program Files (x86)\Rust 1.2\bin\rustlib\i686-pc-windows-gnu\lib" "e:\Rust\DBTools\DBAnalytics\target\debug\DBAnalytics.o" "-o" "e:\Rust\DBTools\DBAnalytics\target\debug\DBAnalytics.dll" "e:\Rust\DBTools\DBAnalytics\target\debug\DBAnalytics.metadata.o" "C:\Program Files (x86)\Rust 1.2\bin\rustlib\i686-pc-windows-gnu\lib\libstd-11582ce5.rlib" "C:\Program Files (x86)\Rust 1.2\bin\rustlib\i686-pc-windows-gnu\lib\libcollections-11582ce5.rlib" "C:\Program Files (x86)\Rust 1.2\bin\rustlib\i686-pc-windows-gnu\lib\librustc_unicode-11582ce5.rlib" "C:\Program Files (x86)\Rust 1.2\bin\rustlib\i686-pc-windows-gnu\lib\librand-11582ce5.rlib" "C:\Program Files (x86)\Rust 1.2\bin\rustlib\i686-pc-windows-gnu\lib\liballoc-11582ce5.rlib" "C:\Program Files (x86)\Rust 1.2\bin\rustlib\i686-pc-windows-gnu\lib\liblibc-11582ce5.rlib" "C:\Program Files (x86)\Rust 1.2\bin\rustlib\i686-pc-windows-gnu\lib\libcore-11582ce5.rlib" "-L" "e:\Rust\DBTools\DBAnalytics\target\debug" "-L" "e:\Rust\DBTools\DBAnalytics\target\debug\deps" "-L" "C:\Program Files (x86)\Rust 1.2\bin\rustlib\i686-pc-windows-gnu\lib" "-L" "e:\Rust\DBTools\DBAnalytics\.rust\bin\i686-pc-windows-gnu" "-L" "e:\Rust\DBTools\DBAnalytics\bin\i686-pc-windows-gnu" "-Wl,-Bstatic" "-Wl,--whole-archive" "-l" "CDbax" "-Wl,--no-whole-archive" "-Wl,-Bdynamic" "-l" "ws2_32" "-l" "userenv" "-l" "advapi32" "-shared" "-l" "compiler-rt"
note: Warning: corrupt .drectve at end of def file
Cannot export ??_C#_0M#LACCCNMM#hello?5world?$AA#: symbol not found
The library is build on MSVC2013 as a simple static lib. The string "hello world" is in the data section, so I wouldn't expect it to cause a link error. Are there some specific settings I need to be aware about when linking with C libraries on windows?
Btw it's 32bit MSVC lib.
Ok, a few things. First of all, there's no such thing as a "static DLL": a DLL is a dynamically linked library.
Secondly, Rust uses the MinGW toolchain and runtime. Mixing MSVC and MinGW runtimes can cause odd things to happen, so it's probably best avoided if at all possible. Rust has only recently landed very early support for building using the MSVC runtime.
However, you can get this specific example to work, apparently without any ill effects. You just need to change a few things:
You need to use a dynamic library; my understanding is that this makes bad interactions a little less likely.
You need to actually compile say_hello with C linkage, not C++ linkage. You did this in the header, but not in the source file.
You need to publicly export say_hello from the library.
Thus:
hello.rs:
#[link(name="hello", kind="dylib")]
extern {
fn say_hello();
}
fn main() {
unsafe { say_hello(); }
}
hello.h:
#ifndef HELLO_H
#define HELLO_H
extern "C" {
__declspec(dllexport) void say_hello();
}
#endif
hello.cpp:
#include <cstdio>
#include "hello.h"
void say_hello() {
printf("hello world\n");
}
build.cmd
cl /LD hello.cpp
rustc -L. hello.rs
On my machine, this produces hello.exe and hello.dll; when run, hello.exe prints out hello world.

GCC errors out on code that used to work fine

I have a program that has successfully compiled in the past, but now I get a bunch of errors.The source code is just:
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
int main()
{
int fd;
fd = creat("datafile.dat", S_IREAD | S_IWRITE);
if (fd == -1)
printf("Error in opening datafile.dat\n");
else
{
printf("datafile.dat opened for read/write access\n");
printf("datafile.dat is currently empty\n");
}
close(fd);
exit (0);
}
Now I get the errors:
cre.C:8:54: error: ‘creat’ was not declared in this scope
cre.C:16:17: error: ‘close’ was not declared in this scope
cre.C:17:16: error: ‘exit’ was not declared in this scope
Sometimes I get an error about gxx_personality_v0 instead, and sometimes I get no error at all! I've tried updating gcc, but the problem remains. What's going wrong?
OS UBUNTU 12.1 on vaio laptop
From your error messages I see that you called your file cre.C. gcc is case-sensitive for file names: try naming it cre.c and compiling it.
$ LANG=C cc -o foo foo.C
foo.C: In function 'int main()':
foo.C:8:54: error: 'creat' was not declared in this scope
foo.C:16:17: error: 'close' was not declared in this scope
foo.C:17:16: error: 'exit' was not declared in this scope
but
$ LANG=C cc -o foo foo.c
foo.c: In function 'main':
foo.c:17:9: warning: incompatible implicit declaration of built-in function 'exit' [enabled by default]
As noted in a comment, a file with .C extension is handled by the C++ compiler, thus you are seeing those errors.
Read the man pages for the creat, close, and exit functions.
On my system, creat() requires:
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
close() requires:
#include <unistd.h>
and exit() requires:
#include <stdlib.h>
As for why the code was compiling before, it's hard to tell. Perhaps the compiler was being invoked in a more permissive mode that didn't complain about missing function declarations, or perhaps some of the headers you do include have #include directives for the headers you need.