libFoundation - Cannot determine the Objective-C runtime


#1

Hi everyone!

I’m trying to “habitatize” a third party/vendor application that depends on libFoundation. There’s no libFoundation in core, so I guessed I’d have to write that first - however, I hit an issue in the do_build method, where I keep on getting an “Objective-C runtime” issue.

output of ./configure

checking host system type... Invalid configuration `x86_64-pc-linux-gnuoldld': machine `x86_64-pc' not recognized


*************** Warning ****************
This package was not ported to running operating system.
We'll use the default configuration file ./config//.h.
****************************************

./configure: line 684: test: =: unary operator expected
checking for a BSD compatible install... /hab/pkgs/core/coreutils/8.25/20170513213226/bin/install -c
checking for ranlib... ranlib
checking for gcc... gcc
checking whether the C compiler (gcc -I/hab/pkgs/core/glibc/2.22/20170513201042/include -I/hab/pkgs/core/glibc/2.22/20170513201042/include -I/hab/pkgs/core/gcc/5.2.0/20170513202244/include -L/hab/pkgs/core/glibc/2.22/20170513201042/lib -L/hab/pkgs/core/glibc/2.22/20170513201042/lib -L/hab/pkgs/core/gcc/5.2.0/20170513202244/lib) works... yes
checking whether the C compiler (gcc -I/hab/pkgs/core/glibc/2.22/20170513201042/include -I/hab/pkgs/core/glibc/2.22/20170513201042/include -I/hab/pkgs/core/gcc/5.2.0/20170513202244/include -L/hab/pkgs/core/glibc/2.22/20170513201042/lib -L/hab/pkgs/core/glibc/2.22/20170513201042/lib -L/hab/pkgs/core/gcc/5.2.0/20170513202244/lib) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for POSIXized ISC... no
checking how to run the C preprocessor... gcc -E
checking for gmake... no
checking for gnumake... no
checking for make... no
checking for the C structures alignment... 8
checking for dlopen in -ldl... yes
checking for pthread_create in -lpcthread... no
checking for pthread_create in -lpthread... yes
checking for sqrt in -lm... yes
checking for chown in -lnsl... yes
checking for accept in -lsocket... no
checking for  in -lwsock32... no
checking for  in -ladvapi32... no
checking for the Objective-C runtime...
configure: error: Cannot determine the Objective-C runtime! Probably you have to specify some additional libraries needed to link an ObjC program

The actual plan.sh is pretty straightforward currently:

pkg_name=libFoundation
pkg_description="libFoundation"
pkg_origin=escapetechnology
pkg_maintainer="Escape Technology Development <development@escape-technology.com>"
pkg_license=('BSD')
pkg_version=0.9.0
pkg_source=https://sourceforge.net/projects/libfoundation/files/${pkg_name}/${pkg_version}/${pkg_name}-${pkg_version}.tar.gz
pkg_shasum=8439a4a60fba6d8eced64787f0dc6228138d6ec87713bf8534849dac4c81b159
pkg_deps=(core/glibc)
pkg_build_deps=(core/glibc core/gcc core/gnupg)

do_build() {
    cd ${HAB_CACHE_SRC_PATH}/${pkg_name}/${pkg_name}
    ./configure
    make
}

Thanks in advance for your help!


#2

I think you’ve got a couple things going on here.

First checking host system type... Invalid configuration 'x86_64-pc-linux-gnuoldld': machine 'x86_64-pc' not recognized seems like the appropriate build triple isn’t being auto-discovered with a generic ./configure call. However that wouldn’t inherently preclude a build from happening.

What’s actually causing your build to die is your package is expecting Objective-C to be available but it’s not included in your list of package deps. We don’t currently have a core/gcc-objc package or a core/gnustep package which I think are going to keep you from being able to build this library.

That being said - I think you mentioned this is COTSoftware? We might have an easier way for you to package this up if you’re in a situation where you always deploy to the same operating system.


#3

Ok, so it’d easily lead me down into a rabbit hole of plans to get to being able to build the software we would like to build.

Sounds interesting! Yes, it’s COTS software; would you be able to point me towards the easier way to package this up? We would be open to always deploying to the same OS.

Thanks in advance!


#4

We’ve been planning to write up a walk-through on how to do that so maybe this is just the push we need to get up and get it done!

First a couple questions - are you packaging up COTS where you have access to an RPM or DEB file that you’re using today?


#5

Yep, I’ve got access to an RPM!


#6

Ok cool I’ll get a guide written up on this and link you back to it here. I’ll get started on it today and hopefully have something useful for you in no time!


#7

Amazing!

Happy to give the guide some exercise and feed back!


#8

So I can’t guarantee it will totally unblock you because it’s going to be use-case specific but you can take a look here now: Using Habitat with COTS


#9

That has been a great help @eeyun; I’ve been able to package up the (COTS) application with Habitat now!

FYI: for my use-case I had to add in an empty do_strip method.

Thank you for your help!


#10

Wonderful, I’m going to mark this as the solution!