<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Unresolved external</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/16276/unresolved-external</link><description> I started a new project with an LPC2106 cpu. 
There are two files in it: blinky.c and time.c 
In Blinky.c I declare: 
 
extern void init_time(void); 
 
And call it in the main function. 
Function is written in time.c 
 
When I link I get a undefined</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/152501?ContentTypeID=1</link><pubDate>Tue, 09 Dec 2003 04:23:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:58748d1b-8e72-409c-a79e-a01a4ee9bf2a</guid><dc:creator>Helge FabriciusHansen</dc:creator><description>&lt;p&gt;Looks like the example program from Keil support only runs on the simulator, not the real chip.&lt;br /&gt;
There are no interrupts generated in real target.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/151701?ContentTypeID=1</link><pubDate>Thu, 04 Dec 2003 12:14:30 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a4950dfc-be0f-408a-b6e3-f645a3ae8aaf</guid><dc:creator>Drew Davis</dc:creator><description>&lt;p&gt;But &amp;quot;Unix&amp;quot; is also the source of most if not all of those other extensions as well.  There had to be some sub-culture that thought .C was a great idea.  It&amp;#39;s even more cute than .cxx.  (See, the plus signs in .c++ are rotated 45 degress and become x&amp;#39;s...)  So I was wondering, which &amp;quot;Unix&amp;quot;, or school?  Is it AT&amp;amp;T thing, or Berkeley, or MIT, or Sun, or NeXT-ish?&lt;br /&gt;
&lt;br /&gt;
Relying only upon case to distinguish two identifiers is a poor design choice, IMO.  I remember once having to deal with some code where the author liked to declare things &amp;quot;Static&amp;quot;, which was of course variably #define&amp;#39;d to mean almost completely not what you thought it did.  Or imagine filling up your 8051 code with references to &amp;quot;p0&amp;quot; and &amp;quot;ie&amp;quot; that are just ordinary data.  Why doesn&amp;#39;t &amp;quot;ResetCPUWatchdog()&amp;quot; do the same thing as &amp;quot;ResetCpuWatchdog()&amp;quot;, and are you really going to remember that late at night before the deadline?  Should &amp;quot;RM -f&amp;quot; (read memory, fast) really exist in your shell next to &amp;quot;rm -f&amp;quot;?&lt;br /&gt;
&lt;br /&gt;
There&amp;#39;s a reason stricmp() and friends exist.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/150993?ContentTypeID=1</link><pubDate>Thu, 04 Dec 2003 10:45:28 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:01130927-cc1c-4621-a80a-6714ce9aafe8</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;i&gt;The uppercase C was just asking for trouble, though; I&amp;#39;m not sure where that convention was used.&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
On Unix, of course, where filenames are case-sensitive as god intended ;-) The way the Microsoft platforms treat letter case in filenames (&amp;quot;case-preserving, but not case-respecting&amp;quot;) is atrocious, IMHO.  It&amp;#39;s a hysterical remnant from the original QDOS&lt;br /&gt;
(and thus from CP/M) which has no business still remaining in all current incarnations of Windows today.  They ought to have killed it in the first edition of NT, but they didn&amp;#39;t.&lt;br /&gt;
&lt;br /&gt;
The DOS and Windows ports of GNU software&lt;br /&gt;
(DJGPP, MinGW, cygwin) all faced this same problem at some time, and no-one found a better solution yet than the classic &amp;quot;Don&amp;#39;t do that, then!&amp;quot; workaround.&lt;br /&gt;
&lt;br /&gt;
IMHO, Keil should put a catch for this into uVision. At least show a warning dialog if a file *.C is added to a project and offer to add it as *.c instead...&lt;br /&gt;
&lt;br /&gt;
Note that lower-casing all extensions unambiguously would be a bad plan because of the distinction between *.s and *.S.  Keil ARM projects may well want to have *.S files in them!&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/151702?ContentTypeID=1</link><pubDate>Thu, 04 Dec 2003 10:37:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:659ea3b2-f553-46f5-8c81-957ccb6da4b3</guid><dc:creator>Keil Software Support Intl.</dc:creator><description>&lt;p&gt;Actually we have completed your example. It is available at:&lt;br /&gt;
&lt;a href="http://www.keil.com/download/files/lpc2100_blinky.zip"&gt;http://www.keil.com/download/files/lpc2100_blinky.zip&lt;/a&gt;&lt;br /&gt;
&lt;br /&gt;
Detailed information can be found in the Abstract.txt file that comes with the example. It is tested with the simulator (but should also run on real hardware).&lt;br /&gt;
&lt;br /&gt;
This example shows:&lt;br /&gt;
  - how to setup the Vector Interrupt controller.&lt;br /&gt;
  - how to setup timer0 for timer interrupts.&lt;br /&gt;
  - how to put the device into power-down mode.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/150986?ContentTypeID=1</link><pubDate>Wed, 03 Dec 2003 18:42:53 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:28e306c1-8e43-4f56-8d5e-bd921cee8d9c</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;More specifically:&lt;br /&gt;
&lt;br /&gt;
&lt;a href="http://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#Overall%20Options" target="_blank"&gt;http://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#Overall%20Options&lt;/a&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/150987?ContentTypeID=1</link><pubDate>Wed, 03 Dec 2003 18:39:08 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a16a15bb-ce11-4283-9b96-59bf2fdf7b3f</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;i&gt;&amp;quot;I&amp;#39;m not sure where that convention was used&amp;quot;&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
Remember that GNU is of &lt;b&gt;UNIX&lt;/b&gt; origin; to understand these things, you have to think like a &lt;b&gt;UNIX&lt;/b&gt; hacker (in the benign sense of the word).&lt;br /&gt;
&lt;br /&gt;
To a &lt;b&gt;UNIX&lt;/b&gt; hacker it is perfectly fine, reasonable and &lt;i&gt;&lt;b&gt;commonplace&lt;/b&gt;&lt;/i&gt; to find that a lowercase &amp;#39;c&amp;#39; has a totally and completely different meaning to an uppercase &amp;#39;C&amp;#39;.&lt;br /&gt;
&lt;b&gt;UNIX&lt;/b&gt; hackers find this perfectly natural; they will find it just as hard to understand how a Windows user could even consider the possibility that &amp;quot;blinky.c&amp;quot; would be in any way equivalent to &amp;quot;blinky.C&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Since a lowercase &amp;quot;.c&amp;quot; suffix was well established as indicating a &amp;#39;C&amp;#39; source file, it is not surprising that &lt;b&gt;UNIX&lt;/b&gt; hackers should think of using &amp;quot;.C&amp;quot; for C++ source - since C++ is effectively a &amp;quot;bigger&amp;quot; &amp;#39;C&amp;#39;, it would make sense (to them) to to a &amp;quot;big&amp;quot; (uppercase) &amp;quot;.C&amp;quot; to distinguish it!&lt;br /&gt;
&lt;br /&gt;
It&amp;#39;s a cultural thing!&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/150514?ContentTypeID=1</link><pubDate>Wed, 03 Dec 2003 16:03:31 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:fa6045f8-e166-4bce-909e-937d9595dd0c</guid><dc:creator>Drew Davis</dc:creator><description>&lt;p&gt;The -x &lt;i&gt;language&lt;/i&gt; option for GCC allows you to specify the language of input files, overriding the detection done on the basis of the file extension.&lt;br /&gt;
&lt;br /&gt;
(And it is just the extension, not the whole file name in uppercase.  &amp;quot;blinky.C&amp;quot; would also be treated as a C++ file.  .cc, .cp, .cxx, .cpp, .CPP, .c++, and .C are all extensions that indicate a C++ file to GCC.  Back in the day, no one was quite sure what the &amp;quot;obvious&amp;quot; extension for C++ ought to be, particularly since &amp;quot;+&amp;quot; is not often allowed in filenames by various OSes.  The uppercase C was just asking for trouble, though; I&amp;#39;m not sure where that convention was used.)&lt;br /&gt;
&lt;br /&gt;
&lt;a href="http://gcc.gnu.org/onlinedocs/gcc/Invoking-GCC.html" target="_blank"&gt;http://gcc.gnu.org/onlinedocs/gcc/Invoking-GCC.html&lt;/a&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/143927?ContentTypeID=1</link><pubDate>Wed, 03 Dec 2003 15:31:42 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:4512bbcc-93a7-49f0-a8e7-a5847d33f575</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;Is there a command-line option to disable this?&lt;br /&gt;
(&lt;i&gt;eg,&lt;/i&gt; like Borland has an option to ignore a &lt;b&gt;.cpp&lt;/b&gt; extension, and compile the file as plain &amp;#39;C&amp;#39;)&lt;br /&gt;
&lt;br /&gt;
Or an option that the functions are to be generated with plain &amp;#39;C&amp;#39; naming &amp;amp; calling conventions?&lt;br /&gt;
&lt;br /&gt;
You may need some time to check this out - I remember how long the list of GCC arguments was about 4 years ago...!  ;-0&lt;br /&gt;
&lt;br /&gt;
Of course, being open-source, you could always add one if it doesn&amp;#39;t already exist...!   ;-)&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/132040?ContentTypeID=1</link><pubDate>Wed, 03 Dec 2003 07:12:21 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:71ef225f-2262-4bf9-aeb7-4539917f32bc</guid><dc:creator>Helge FabriciusHansen</dc:creator><description>&lt;p&gt;Thanks Hans-Bernhard...&lt;br /&gt;
&lt;br /&gt;
Your answeer came at the same time as I wrote mine...&lt;br /&gt;
&lt;br /&gt;
//Helge&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/131747?ContentTypeID=1</link><pubDate>Wed, 03 Dec 2003 07:09:18 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d328da0e-d839-4dcf-8255-77f5100cc162</guid><dc:creator>Helge FabriciusHansen</dc:creator><description>&lt;p&gt;It looks like Nohau, Sweden solved the problem....&lt;br /&gt;
&lt;br /&gt;
Problem can be located to the GCC compiler.&lt;br /&gt;
&lt;br /&gt;
Filenames in capital letters are considered to be C++ files and function calls are made in that style.&lt;br /&gt;
&lt;br /&gt;
By renaming BLINKY.C to blinky.c the problem was solved.&lt;br /&gt;
&lt;br /&gt;
Do I need to add any personal opinion about this????&lt;br /&gt;
&lt;br /&gt;
//Helge&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/137767?ContentTypeID=1</link><pubDate>Wed, 03 Dec 2003 07:06:41 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:84a618a5-a339-4433-8d9c-1a0428e5046a</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;Your problem is the &lt;b&gt;name&lt;/b&gt; of the &lt;i&gt;blinky.c&lt;/i&gt; source file.  It&amp;#39;s actually in all upper-case: &lt;i&gt;BLINKY.C&lt;/i&gt;.  Now the Keil ARM tools are based on GNU compilers, which are Unix-born, and thus do care about the case of filenames.  From GCC&amp;#39;s point of view, &amp;quot;BLINKY.C&amp;quot; is a &lt;b&gt;C++&lt;/b&gt; file name, and so it compiled the source as C++.  C++ puts a lot more information into a function&amp;#39;s linker-visible name than C (google:&amp;quot;name mangling&amp;quot;), which break direct link compatibility with C.  Thus your problem.&lt;br /&gt;
&lt;br /&gt;
Proposed solution: remove BLINKY.C from the project, rename the file to lower-case, and add it back to the project under the new name.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/129825?ContentTypeID=1</link><pubDate>Wed, 03 Dec 2003 04:01:26 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a2a92270-bbd5-430e-a105-fc1d17e05d70</guid><dc:creator>Helge FabriciusHansen</dc:creator><description>&lt;p&gt;You are correct. I did leave out the void when writing the function. Have tried som many ways....&lt;br /&gt;
But problem is still there, with or without the &amp;quot;void&amp;quot;.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/122217?ContentTypeID=1</link><pubDate>Wed, 03 Dec 2003 03:22:37 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2ef8c9c4-f466-414e-8bdc-da9bca7d4484</guid><dc:creator>Michael D</dc:creator><description>&lt;p&gt;You should really have checked (your declaration is the same as the definition) before posting a message like that.  They look obviously different to me.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/110640?ContentTypeID=1</link><pubDate>Wed, 03 Dec 2003 02:19:20 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:68f57003-487e-4177-83d9-98a72efa18f6</guid><dc:creator>Helge FabriciusHansen</dc:creator><description>&lt;p&gt;The declaration is the same as it is possible to see if the project is downloaded.&lt;br /&gt;
I think I will wait for support to answeer my question. It looks like nobody else have used the ARM...&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/95952?ContentTypeID=1</link><pubDate>Tue, 02 Dec 2003 19:25:57 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:1699ddf0-ec55-4d97-a8e0-60995c7d809c</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;i&gt;&amp;quot;Absolutely sure! Both time.c and blinky.c shows up in the project window. Both are compiled.&amp;quot;&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
That answers Stefan&amp;#39;s 1st question, but not his 2nd:&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;&lt;b&gt;Is the declaration of init_time in time.c is *exactly* the same, ie void init_time(void)?&lt;/b&gt;&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;&amp;quot;Still... Why the &amp;quot;Z9&amp;quot; in the beginning of init_timer....?&amp;quot;&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
It is quite possible that the compiler could add prefixes and/or suffixes related to the type of the function, its parameters, &lt;i&gt;etc&lt;/i&gt;.&lt;br /&gt;
That&amp;#39;s why Stefan&amp;#39;s 2nd question is so important!&lt;br /&gt;
&lt;br /&gt;
One way to guarantee that the &lt;i&gt;declaration&lt;/i&gt; matches the &lt;i&gt;definition&lt;/i&gt; is to put the &lt;i&gt;declaration&lt;/i&gt; of init_time() in a header file - say time.h - and #include that it &lt;b&gt;both&lt;/b&gt; main.c &lt;b&gt;&lt;i&gt;and&lt;/i&gt;&lt;/b&gt; time.c. That way, the compiler can give an error/warning if the &lt;i&gt;declaration&lt;/i&gt; does not match the &lt;i&gt;definition&lt;/i&gt;, since it can see both when it compiles time.c!&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/110631?ContentTypeID=1</link><pubDate>Tue, 02 Dec 2003 10:34:21 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b11ca737-264b-4ef0-ae4c-e5324257a362</guid><dc:creator>John Donaldson</dc:creator><description>&lt;p&gt;Sorry, I can&amp;#39;t compile ARM projects.&lt;br /&gt;
&lt;br /&gt;
Stefan&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/95963?ContentTypeID=1</link><pubDate>Tue, 02 Dec 2003 09:42:36 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:60bd94ad-e588-43e2-b9ca-7c97c7e142f8</guid><dc:creator>Helge FabriciusHansen</dc:creator><description>&lt;p&gt;The complete project can be found here:&lt;br /&gt;
&lt;br /&gt;
&lt;a href="http://www.fabricius.nu/blinky.zip" target="_blank"&gt;http://www.fabricius.nu/blinky.zip&lt;/a&gt;&lt;br /&gt;
&lt;br /&gt;
It is only 18 kbyte&lt;br /&gt;
&lt;br /&gt;
//Helge&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/72118?ContentTypeID=1</link><pubDate>Tue, 02 Dec 2003 09:26:47 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:36c58510-1a85-4659-abb7-ed9f0fe1456a</guid><dc:creator>Helge FabriciusHansen</dc:creator><description>&lt;p&gt;Absolutely sure! Both time.c and blinky.c shows up in the project window. Both are compiled.&lt;br /&gt;
Still... Why the &amp;quot;Z9&amp;quot; in the beginning of init_timer....?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unresolved external</title><link>https://community.arm.com/thread/41346?ContentTypeID=1</link><pubDate>Tue, 02 Dec 2003 09:20:18 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:885a0a46-fd35-4c42-a4b4-9bc5e2d5d07d</guid><dc:creator>John Donaldson</dc:creator><description>&lt;p&gt;Are you sure that:&lt;br /&gt;
&lt;br /&gt;
1) time.c is definitely included in your project?&lt;br /&gt;
2) The declaration of init_time in time.c is *exactly* the same, ie void init_time(void)?&lt;br /&gt;
&lt;br /&gt;
Stefan&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>