Re: Compiling under Ubuntu 16.04

[Matthew Butch]

Alright, following up on this now that I had some time.

- changed the fobjc-runtime flag
- removed the DCMAKE_ASM_FLAGS flag
- added a prompt function to clean up the code
- added curl as a dependency install
- fixed a bug running the script multiple times
- changed sourcing .bashrc to running GNUstep.sh


Two things I couldn't change: 

- I had to leave DTESTS=OFF. I got errors with CXXException tests not finding 
references such as __cxa_allocate_exception
- I had to build GNUstep-make twice
        - If I only built the second one, GNUstep-base would not build because 
it couldn’t find libobjc2
        - If I only built the first one, apps that use lib dispatch would not 
compile as it could not find it (even if I swapped the order of libdispatch and 
GNUstep-make)

I’m not sure how to fix those issues.

--

Matthew Butch

"fiat justicia ruat colelum"
(let justice be done though the heavens may fall)

Sent with Mac OS X El Capitan Mail 9.2 (3112)








> On Aug 26, 2016, at 09:41, David Chisnall <theraven@sucs.org> wrote:
> 
> 
>> On 26 Aug 2016, at 14:28, Matthew Butch <apple4ever@me.com> wrote:
>> 
>> Thanks for the comments! Mine are below:
>> 
>> 
>>> On Aug 26, 2016, at 04:46, David Chisnall <theraven@sucs.org> wrote:
>>> 
>>> Please will you remove the first build of GNUstep Make.  Neither 
>>> libdispatch nor libobjc2 need GNUstep Make (in the case of libobjc2, 
>>> intentionally to avoid a circular dependency).
>>> 
>>> If -Make is not installed, then libobjc2 will install as a normal library, 
>>> just set the prefix to whatever you want (it defaults to /usr/local, you 
>>> probably want /usr on Ubuntu).
>> 
>> I did see a previous post on the list here about that. But I could not get 
>> it to work. I could not get further builds of GNUstep to properly build and 
>> use either /usr or /usr/local when libobjc2 was installed there. 
>> 
>> If you have any suggestions as to the correct flags to get it to work, I’d 
>> be happy to try again. 
> 
> I’m not sure of any special flags that are needed.  On FreeBSD, we ship 
> packages of libobjc2 that don’t depend on any other bits of GNUstep to build, 
> install in /usr/local, and are picked up automatically by GNUstep Make with 
> no other issues.  What errors do you see?
> 
>>> Ubuntu 16.04 includes clang 3.8 (clang-3.8 package), which is ample for 
>>> compiling modern Objective-C code (and, for the next couple of weeks, is 
>>> the latest release), so it’s probably more sensible to install that than to 
>>> build from source.  Even better, they’ve now fixed the idiocy from Ubuntu 
>>> 14.04 where you then had to force-deinstall a bunch of gcc packages that 
>>> they made the clang package depend on to get a working compiler.
>> 
>> Which I do. Maybe you were looking at the 14.04 & 15.04 scripts which I 
>> didn’t change? 
> 
> Ooops!  I didn’t scroll back up as far as I thought I’d done.
> 
>> 
>>> You will need to update the [OBJ]C[XX]FLAGS everywhere because now clang / 
>>> clang++ are called clang-3.8 and clang++-3.8.
>> 
>> Do I? Everything seemed to work fine with the repository installed version 
>> without doing that. 
> 
> Ah, I didn’t realise there was also a clang package that installs sensible 
> symlinks.  Ignore me.
> 
>> 
>>> I don’t know why you think you need '-DCMAKE_ASM_FLAGS=-c’ in the libobjc2 
>>> build.  I just tried cmake -G Ninja -DCMAKE_C_COMPILER=clang-3.8 
>>> -DCMAKE_CXX_COMPILER=clang++-3.8 on Ubuntu 16.04 and it seemed to work.
>>> It’s also probably not a good idea to pass -DTESTS=OFF - it only takes a 
>>> few extra seconds on a moderately modern machine to build and run the tests 
>>> and you get a bit of sanity checking early on from doing so.
>> 
>> That was the recommendation from the INSTALL for libobjc2 
>> (https://github.com/gnustep/libobjc2/blob/master/INSTALL#L40)
>> 
>> If you think they aren’t needed, I can try with out them. 
> 
> This was a work-around for a cmake bug, which appears to now be fixed.
> 
>> 
>>> Please don’t use -fobjc-nonfragile-abi, it’s been deprecated for years.  
>>> The correct flag is -fobjc-runtime=gnustep-1.8.
>> 
>> Interesting. I didn’t see that anywhere. Will have to update this page to 
>> note:
>> 
>> http://wiki.gnustep.org/index.php/ObjC2_FAQ
>> 
>> I will correct it. 
> 
> This page is far less horribly out of date than it used to be, but it’s still 
> a bit in need of love.
> 
>> 
>>> In theory, the libdispatch0 package from Ubuntu ought to work, though I’ve 
>>> not tested it
>> 
>> I believe I tested it and it didn’t work. But right now I can’t recall what 
>> I ran into.
>> 
>>> This line:
>>> 
>>> source ~/.bashrc
>>> 
>>> Is probably dangerous.  You’re already sourcing GNUstep.sh earlier and you 
>>> may end up with something very confusing, as many people have .bashrc 
>>> scripts that don’t expect to be sourced more than once in a shell.  
>>> Similarly, the advice at the end is bad and you should tell people to 
>>> source GNUstep.[c]sh, not re-source their .bashrc into a shell that’s 
>>> already loaded it (or into a shell that may not understand it if bash is 
>>> not their current shell).
>> 
>> Hmm good point. I added that line because for some reason building the apps 
>> would give me errors without it. It grabbed the idea from the old script, 
>> and it did work for me- but it was a fresh install. And I originally tried 
>> without that advice at the end, but I still got errors trying to build test 
>> apps. Maybe better advice would be to close and re-open the terminal.
> 
> If you’re installing GNUstep-Make twice, then you might accidentally pick up 
> settings from the old one, which is part of the reason for not doing this.
> 
>> 
>>> The script would be a lot more readable if this were in a function, not 
>>> copied and pasted a dozen times:
>>> 
>>> if [ "$PROMPT" = true ] ; then
>>> echo -e "\n\n"
>>> read -p "${GREEN}Press enter to continue...${NC}”
>>> fi
>> 
>> I agree- I thought about it before I uploaded it. But I wanted to get it out 
>> for critiquing and figured I’d change it when I’d make other changes. 
> 
> Thanks for doing this,
> 
> David
> 
>