Author Topic: NASM and EXTERN  (Read 10858 times)

Offline ad31677

  • New Member
  • Posts: 1
« on: April 22, 2012, 03:54:10 PM »
Hi, All

I haven't seen this discussed (obviously) in a topic search so I thought I'd stick my head above the parapet...

I am curious about NASM's implementation of the "EXTERN" word in two respects, both in comparison to C's.  Context: suppose one has a large library of assembly language functions, maybe 30 functions, with each function having its own implementation file but you have just one single header file to declare each function as EXTERN.  The idea being a bit like libc where you only have to include a few header files but you have access to a large range of functions and you only get the ones in your binary that you actually used.  I am using NASM v2.09.08 from Ubuntu 11.10.


1. If one declares something EXTERN in a header file in NASM, then you can't later provide a definition for it.  In C, one can declare something extern in a header file and then provide the implementation and the C compiler doesn't complain.  This makes it tricky to have a file in the library build which includes the library's own header file(s) without also having to use macros to declare a symbol correctly as EXTERN/GLOBAL depending upon whether it's currently the file being assembled.   My reading of the manual is that this is quite intentional.

2. If one declares a symbol EXTERN in NASM, then any object file produced seems to contain an undefined reference to said symbol regardless of whether the symbol was actually referenced by an instruction or data element.  This makes it difficult to use only the bits of the library actually used in your code.

So maybe I am doing something obviously wrong in my use of NASM.  Any pointers  therefore would be greatly appreciated.

Best regards,

Offline Keith Kanios

  • Full Member
  • **
  • Posts: 383
  • Country: us
    • Personal Homepage
« Reply #1 on: April 22, 2012, 07:48:08 PM »
Your conclusions are correct. GLOBAL and EXTERN are quite literal in NASM.

Without using macro magic, your next option is to make include files that have the declared EXTERN entries, and make sure that the code/module with the defined GLOBAL entries does not include said file with EXTERN entries. To placate your second point, declare individual EXTERN entries within the desired source code file.

NASMX solves this with a standard import/export system. Basically, macros are used to ensure that EXTERN is issued only if needed.