gcc compiling tips

I've removed advertising from most of this site and will eventually clean up the few pages where it remains.

While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.

If you found something useful today, please consider a small donation.

Some material is very old and may be incorrect today

© December 2004 Tony Lawrence

This is good general advice on code porting.

I would add a few things. First, you may not need to port - the Linux abi may allow you to run your program without porting. However, there still may be hard paths and references to non-existent programs (or worse, references to programs that exist but have different function!)

I'd recommend reading Advanced Programming in the Unix Environment and be aware that "make" files that say they provide support for your target OS may be a good natured guess by someone trying to be helpful - they may never have actually compiled on that system!

From - Fri Sep 24 15:36:26 1999
Xref: world comp.unix.sco.misc:106012
Path: world!newsfeed.mathworks.com!btnet-peer!btnet!newspeer.clara.net!news.clara.net!peer.news.zetnet.net!peer.news.bb.u-net.net!u-net!yama.mcc.ac.uk!cs.man.ac.uk!smallshaw
From: [email protected] (Andrew Smallshaw)
Newsgroups: comp.unix.sco.misc
Subject: Re: gcc compiling notes
Date: 24 Sep 1999 14:51:25 GMT
Organization: Dept of Computer Science, University of Manchester, U.K.
Lines: 61
Message-ID: <[email protected]> 
NNTP-Posting-Host: ug029.cs.man.ac.uk
NNTP-Posting-User: smallsa7
User-Agent: slrn/0.9.5.4 (UNIX)
X-Mozilla-Status: 8011

On Fri, 24 Sep 1999 01:00:30 -0400, Brian K. White wrote:
> Is there a repository of porting/compiling notes for compiling various
> free apps on OS 5.0.5 using gcc?

> I didn't include detailed make error messages because I'm not really
> looking for help with libjpeg. I'm looking for help with 'stuff' the
> general points to see to in any random makefile for super whiz-bang gnu
> app xyzX

When it comes to porting, it's helpful to know APIs of various Unix systems 
inside out and back to front, but the best way of doing this is probably by 
porting.  It appears you want general pointers on porting so a few tips:

1)  Link errors

    If you successfully compile an application but get errors on linking,
    do a 'man function-name' for the missing function.  In the syntax section,
    you'll see a line 'cc ... -l(library)'.  You need to add the -l bit to
    get the required library linked in.

2)  Apparently missing functions 

    It's possible that what is needed is there, but defined in a place
    other than where the program expects it.  'man function-name' will
    tell you what headers you need to pick up the function declaration.

3)  Apparently missing #defines and/or variables

    Again, these may be present, but in a non-standard location.  Try 
    searching scohelp for the term you're looking for, and include
    the relevant headers.  Alternatively you can find and grep on 
    /usr/include, /usr/local/include, etc.

4)  Really missing functions, #defines, or variables

    These fall into two categories: those that are included in other Unix 
    systems, and those that belong to third party libraries.

    Third party libraries first: find out which library you need, get it
    and port that.  This can get a bit demoralising when you have to port
    several libraries before you can get on with what you're trying to do.

    Other systems: read up on what the function in question does (most
    Unixes have on-line docs somewhere on the net), and assess how tricky
    it will be to implement.  Some times you can create a simple wrapper
    around facilities you do have, or you may have to re-write the 
    problematic code to use your system's facilities.

5)  #ifdefs

    These are your friends.  You may have done a './configure', but the 
    #defines still may not be quite right.  Look around the problematic
    code and see if there are any #ifdefs that look like they could solve
    your problem.  If so this is likely to prove the path of least 
    resistance.

This isn't exhaustive, of course.  Feel free to add extra points here.  

-- 
Andrew Smallshaw
[email protected]

From - Mon Jun 19 06:30:17 2000
Path: news.randori.com!hermes.visi.com!news-out.visi.com!newsfeed.direct.ca!newsfeed.icl.net!colt.net!news0.de.colt.net!bignews.mediaways.net!news.vew-telnet.net!news.st-oneline.de!not-for-mail
From: Frank Langelage <[email protected]>
Newsgroups: comp.unix.sco.misc
Subject: Re: [Question] about my LINK errors
Date: Sun, 18 Jun 2000 21:40:56 +0200
Organization: ST-oneline InterNet Service Provider GmbH
Lines: 67
Message-ID: <[email protected]> 
References: <[email protected]> 
NNTP-Posting-Host: line4.st-oneline.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Server-Date: 18 Jun 2000 19:46:31 GMT
X-Mailer: Mozilla 4.61 [de] (X11; I; UnixWare 5 i386)
Xref: news.randori.com comp.unix.sco.misc:61946
X-Mozilla-Status: 8010
X-Mozilla-Status2: 00000000

The order the libraries are named for the link command is wrong.
-lm is behind lgasrfeat.a.
You can add -lm at the and a second time or put your own libraries in front of
the system libs.
        cc voice.o process.o ifunc.o util.o msg_q.o vms.o vms_sub.o ars1.o
ars2.o v_ad.o vms_util.o paramete.o sctools.o guide.o ipc_ex.o faxutil.o fax.o
q_call.o log.o lgasrfeat.a -ldti -ldxyz -lsrl -lm -lfax -lcurses -lsocket -lc
-lgthreads /usr/lib/libgthreads.a -o voice

From - Tue Jun 20 17:58:11 2000
Path: news.randori.com!hermes.visi.com!news-out.visi.com!feeder.via.net!news.he.net!cyclone-transit.snfc21.pbi.net!132.147.128.45!hobbes.sco.com!kauai!jls
From: [email protected] (J. L. Schilling)
Newsgroups: comp.unix.sco.misc,comp.unix.sco.programmer
Subject: Re: warning: #ident is an extension of ANSI C
Followup-To: comp.unix.sco.misc,comp.unix.sco.programmer
Date: 20 Jun 2000 20:15:08 GMT
Organization: SCO, Inc.
Lines: 17
Message-ID: <[email protected]> 
References: <[email protected]> 
Reply-To: [email protected]
NNTP-Posting-Host: kauai.newjersey.sco.com
X-Newsreader: TIN [version 1.2 PL2]
Xref: news.randori.com comp.unix.sco.misc:62046 comp.unix.sco.programmer:6414
X-Mozilla-Status: 8010
X-Mozilla-Status2: 00000000

Jeff Dickens ([email protected]) wrote:

: Recently we moved to version 5.0.5.  Now we get warnings like this:

: "/usr/include/stdlib.h", line 226: warning: #ident is an extension of ANSI C

: [...]

This is a "feature" of the cc -w3 option (highest level warnings).
#ident is indeed not part of strict ANSI C, although warning you about
things inside system headers (which you have no control over) is 
admittedly not very practical.

To eliminate these warnings, use cc -w2 or less.

--
Jonathan Schilling              SCO, Inc.               [email protected]

Also see:

Undefined symbol _fini error
warning: empty translation unit

If you found something useful today, please consider a small donation.

Got something to add? Send me email.

---

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us