My sddc-skeleton Enhancement Quest... autotools skeleton and libcmios

ptitjes · December 14, 2007, 3:17am

Updated :

Starting some documentation : http://www.midibox.org/dokuwiki/howto:dev:autotools-skeleton

New release: 1.9f-r1

Merry Christmas!

Cheers, Didier.

To Do :

Cut libcmios in one object file per function

Changelog :

1.9f-r1 (2007-12-21)

Made mios-pic16-toolchain, libcmios and the skeleton itself to follow the same version scheme (MIOS version - release number)
mios-pic16-toolchain

Fixed installation of tool symbolic links
Fixed management of installation prefix

[*]libcmios: Removed now unused mios_tables.inc

1.9f

[*]Initial release

Hi all,

Time maybe has come for me to publish a bit of my homework during the past months.

In my quest to simplify the C skeleton, i wanted to achieved the following goals:

Not having identical files in different applications
Having a makefile system that is easily extensible (don’t want to have to make rules for simple things and want to make simple rules for complex things), enables directory hierarchies, that encompass by default all my wanted targets (all, clean, install, dist, dist-check…)

Goal 1) required the mios wrapper itself to be put elsewhere than in the skeleton. Why not having a libcmios library ? Hopefully gplib can make shared libraries and gplink can grap object files from them and link them statically inside the application. Cool!
The mios-specific linker scripts also had to be put in a shared location. I decided to follow the usual rules of sharing for cross-compilation… having a directory that is specific for a host platform that contains headers and libraries. (${prefix}/host/)
The mios-specific asm fix script was a problem. But thinking about Goal 2) makes my try the autotools and I quickly understood how they were fullfiling Goal 2) completely. So I decided to make a wrapper script around sdcc, gpasm, gplib and gplink, that would take care of transparently fixing the asm, and that would use the GCC command line style:

C compiler to compile for target processor-vendor-os is processor-vendor-os-gcc

Asm compiler to compile for target processor-vendor-os is processor-vendor-os-as

Librarian tool to make libraries for target processor-vendor-os is processor-vendor-os-ar

Linker for target processor-vendor-os is processor-vendor-os-ld

So here is the result. You can find an attachement in this post that contains

libcmios-1.9f.tar.gz

mios-pic16-toolchain-0.1.tar.gz

mios-c-skeleton/

Possible targets/hosts are:

pic18f452-microchip-mios, pic18f4520-microchip-mios, pic18f4620-microchip-mios, pic18f4685-microchip-mios

Note that pic18f452-mios, pic18f4520-mios, pic18f4620-mios and pic18f4685-mios are automatically expanded.

I will document this better in the Wiki in some days.

Install the toolchain wrapper, libcmios and its linker scripts…:

$ cd mios-pic16-toolchain
$ ./configure --target=pic18f4685-mios --prefix=/usr
$ sudo make install
$ cd ../libcmios
$ ./configure --host=pic18f4685-mios
$ sudo make install

As for the skeleton itself… Modify the configure.in, Makefile.am, src/Makefile.am and main.c… and then configure and make the application :

$ autoreconf --install
$ ./configure --host=pic18f4685-mios
$ make

[mios-autotools-skeleton-1.9f-r1.zip](< base_url >/applications/core/interface/file/attachment.php?id=539)

[mios-autotools-skeleton-1.9f-r1.zip](< base_url >/applications/core/interface/file/attachment.php?id=3681)

ptitjes · December 14, 2007, 12:08pm

Also support for pic18f4685 comes with sdcc-svn (has a package on Gentoo) and gputils-0.13.5!

audiocommander · December 15, 2007, 11:40am

wow, that sounds great!!!

I hope I find some time in the days past christmas to give it a try; got some 4620’s lounging around in drawers that just waited for a service like this ;D

Thanks and Cheers!

Michael

T.K · December 15, 2007, 4:49pm

I find this approach nice. I considered to use autoconf as well at the beginning, but found it complicated and not flexible enough for different operation systems. E.g., under Windows a Cygwin installation is required, but I fear that a normal MIDIbox user is already overloaded enough by installing perl/SDCC and GPASM :-/

Therefore I started the simple “perl makefile generator” approach.

However, this shouldn’t prevent you to start with a more proper setup of the SDCC skeleton! Feel free to enhance it in future, but please also understand that I will continue to maintain the “simple solution”.

Best Regards, Thorsten.

P.S.: converting the wrapper to a shared library is an elegant idea, on the other hand: is the linker able to ignore (not link in) the code which isn’t used by the project? Here I see the only benefit of a library

ptitjes · December 16, 2007, 9:39am

However, this shouldn’t prevent you to start with a more proper setup of the SDCC skeleton! Feel free to enhance it in future, but please also understand that I will continue to maintain the “simple solution”.

Yé! I understand that! I was thinking about that keeping the “simple solution” along to it however when i wrapped the mios wrapper in a library i lost the ability to use the perl script… However i still wish to reintegrate it in a latter time!

P.S.: converting the wrapper to a shared library is an elegant idea, on the other hand: is the linker able to ignore (not link in) the code which isn’t used by the project? Here I see the only benefit of a library

In fact, this is one bonus of the library approach! http://gputils.sourceforge.net/reloc_howto.html says :

gplink will only extract those archive members that are required to resolve external references. So the application won’t necessarily contain the code of all the archive members.

(archive members are individual relocatable object files aka “.o”)

So, this means that the mios wrapper must be split in multiple asm files to make multiple objects. So that the linker extract only the ones needed by the application. So i think, there should be one core object file for the user callback vector definition, and one for each big features : DIN, DOUT,…

But this scratches my head constantly that in fact that should be MIOS itself that should be cut in libraries. A core MIOS with just the bootloader (and MIDI-stuff used for the bootloader) and a series of libraries for each big features. I could help in splitting it if you would choose that for a latter major version of MIOS. If you want i can experiment on that so that we can see if it feasible of not!

PS: Another bonus of the library approach is that i was forced to find a C macro way for defining the MIOS_ENC_TABLE and this is cool

T.K · December 16, 2007, 11:21am

Yes, it would be possible to split the MIOS functions over different .o files instead of using a single kernel, but it’s a different approach and leads to disadvantages. I already evaluated the micro-kernel approach ca. 2 years ago, there are so many dependencies between the modules, that a seperation leads to a higher memory consumption that we currently have if all MIOS functions are included in a static kernel (e.g. you have to isolate internal variables, e.g. by using a stack, and you have to use the 4-byte instructions “goto” and “call” more often than the 2-byte instructions “rgoto” and “rcall”). It’s also more difficult to provide MIOS updates to users who are less experienced with programming like you (don’t know, how many users really know how to recompile an application, especially when they have to use so many different tools).

However, if I would design MIOS today, I would consider this from the beginning, especially because it would free some extra memory for applications which don’t use a graphical display or motorfaders (functions which are only used by a small number of applications). I would also define the function interface SDCC like so that an assembly file conversion, which changes the FSR pointers, wouldn’t be required anymore.

But I don’t plan to do this for MIOS V1, accordingly you don’t need to try this out again - it would be wasted effort…

Splitting the wrapper functions over different files makes sense, I would split them all.

Best Regards, Thorsten.

ptitjes · December 16, 2007, 4:49pm

I see your point for the necessary user skill-level for such an approach… Configuring and compiling my linux kernel seems natural to me now but this has not always been the case.

However, if I would design MIOS today, I would consider this from the beginning, especially because it would free some extra memory for applications which don’t use a graphical display or motorfaders (functions which are only used by a small number of applications). I would also define the function interface SDCC like so that an assembly file conversion, which changes the FSR pointers, wouldn’t be required anymore.

And maybe eliminating the need for a C wrapper completely but providing helper functions like PrintCString()!

But I don’t plan to do this for MIOS V1, accordingly you don’t need to try this out again - it would be wasted effort…

OK! I asked because i have so many other things on fire… However, i understand that you suggest that could be a decision for a redesign/rewrite for a V2 (surely also if it must support not only PIC but another processor family). So when the time will come, I volunteer to help you setting up the tool-chains and splitting MIOS!

Splitting the wrapper functions over different files makes sense, I would split them all.

Heu… not sure to understand! Are you saying you will do it or are you saying that if you were me, you would split each and every function in it own file ?? (Wooow!! :o ::)) In fact, i can see this is the approach they have choosen for the sdcc libs…

I’ll have to make a script to automate this… else I’m too lazy!

T.K · December 16, 2007, 6:19pm

Heu… not sure to understand! Are you saying you will do it or are you saying that if you were me, you would split each and every function in it own file ?? (Wooow!! :o ::))

Yes, thats the way how I normaly create libraries - it’s the most effective way.

In fact, i can see this is the approach they have choosen for the sdcc libs…

I’ll have to make a script to automate this… else I’m too lazy!

You can do this if you have the time, but please do it in a way which allows to rebuild the library on a simple way without the need for installing a massive tool chain. So, rebuilding a .lib file should even work under Windows without installing Cygwin (or another unix environment)

I would use a perl based makefile generator for this, which creates a .bat file (for windows) and a Makefile (for unix) based on an ordered list of all sources.

Once the functions have been extracted, there is no need to re-do this process. So, first check if it is faster to do the extraction by hand (I would estimate an effort of about 15 minutes), or writing a script which you will probably only use one time, and never again

All you need is a powerful text editor (IMHO)

Best Regards, Thorsten.

ptitjes · December 17, 2007, 2:07am

So, rebuilding a .lib file should even work under Windows without installing Cygwin (or another unix environment)

I’m really not sure that you need Cygwin to run autotools on Windows:

http://gnuwin32.sourceforge.net/packages/autotools.htm

But i can’t test that as I don’t have any Windows at hand! And i surely never won’t anymore…

Anyway I don’t know what dev. you can do without any decent make utility.

T.K · December 17, 2007, 12:00pm

The problem is, that you need to specifiy DOS style pathes (with backslash) in the configuration files. For “make” there is the same requirement, and in addition all DOS make implementations I know ignore the PATH variable, so that tools need to be specified with absolute pathes. Accordingly, the Makefile* looks very different.

At least these were the issues which prevented me from setting up the common Makefile approach for the SDCC wrapper, and why I decided to create a simple makefile generator which allows to create a batch file.

I’m not really a DOS/Windows fan (in fact I work under Solaris/Linux @ Work, and mostly under MacOS @ Home), but I find it important to provide an universal solution, so that everybody is able to contribute, and not only a small group of people who have the right OS installed.

We already have this issue with MPASM (which runs only under Windows), please don’t do the same error like me with a new approach.

Best Regards, Thorsten.

ptitjes · December 17, 2007, 6:51pm

According to http://gnuwin32.sourceforge.net/install.html :

The MS-Windows command interpreters, command.com and cmd.exe, understand both the backward slash '' (which is the default) and the forward slash ‘/’ (such as on Unix) in filenames. In general, it is best to use forward slashes, since some programs internally use the filename, e.g. to derive a directory name, and in doing this rely on the forward slash as path separator.

As for the PATH variable i think this has been corrected. And the interest of autotools is that it can generate makefile differently for the platform it runs on. There are also extensive discussion in the autotools’ manuals about support of Win-specific filenames… so this should be tested by one that has Windows. If someone can test autotools on Windows, i likely want to make the autotools skeleton more portable. And again i think there is not too much work.

Else, Cygwin is, IIRC, really easy to install. Something like a two click setup program. Generally, people that begins with programing on Windows never practiced cmd.exe before. So, really, we should immediately recommend them to install Cygwin. Learning DOS shell or learning POSIX shells is the same from a learning curve point of view, except that there are POSIX shells available for all platforms and no other plateform than Windows with a DOS shell.

I completely agree that to reduce work, there should be the minimum of officially supported programming ways. But here is how I see it : MPASM is not a common case as it only runs under Windows. gputils and sdcc runs on all your supported platforms. So why not drop official support of MPASM and let people on their own if they want to experiment with using MPASM.

By the way, it make a while now that I’m really wondering what Midibox’s users are using as development platform… Would you mind if i make a poll on the forum ?

Best regards, Didier.

T.K · December 17, 2007, 7:20pm

As for the PATH variable i think this has been corrected. And the interest of autotools is that it can generate makefile differently for the platform it runs on. There are also extensive discussion in the autotools’ manuals about support of Win-specific filenames… so this should be tested by one that has Windows. If someone can test autotools on Windows, i likely want to make the autotools skeleton more portable. And again i think there is not too much work.

Ok, I will check it this evening and give you feedback. I haven’t expected that the development still continues, I did the evaluations ca. 2 years ago, and only found unix ports with flaws…

completely agree that to reduce work, there should be the minimum of officially supported programming ways. But here is how I see it : MPASM is not a common case as it only runs under Windows. gputils and sdcc runs on all your supported platforms. So why not drop official support of MPASM and let people on their own if they want to experiment with using MPASM.

Problem is, that most of my own assembly programs can only be assembled with MPASM due to the more powerful macro pre-processor. Some time ago I wanted to switch all my programs to a GPASM friendly format without these macros (could be automated easily) but I felt handicaped while programming without my beloved IFSET and IFCLR macros. And there are more complex macros, e.g. in the MBSID firmware, which cannot be replaced on an automated way, and where the code looks really ugly if you try to transform them into multiple lines…

A solution would be to extend the GPASM macro processor, but after I looked into the source code I noticed that this won’t be an easy task (at least for me)

However, the SDCC wrapper on the other hand cannot be used with MPASM. All C based, and some of my newer small applications (like the MBHP_IIC_* and MBHP_USB_PIC firmwares) are completely GPASM compatible.

For people who are not writing so much in assembler, or who are not used to work with complex macros, don’t have any disadvantages here though…

You can start a poll, but I think the result is clear: there will only be one person who prefers to work with MPASM, and thats me

Best Regards, Thorsten.

T.K · December 17, 2007, 8:10pm

Ok, I checked the GNUWIN32 status and found out, that it is very similar as some time ago - you still need Cygwin (at least bash) to use the tools like “configure”, and you need to install a lot of additional packages in order to get the toolchain running.

So, I think that two or three independent windows users should evaluate your approach, if it is easy enough to understand, especially when a certain tool doesn’t work immediately. I won’t give much more comments anymore to ensure that nobody is influenced by my own oppinion (which might be too conservative?).

The result should be a clear picture, if people who have used MPASM (see http://www.ucapps.de/howto_tools_mpasm.html) for assembly based firmwares, or the current SDCC setup http://www.ucapps.de/mios_c.html) in the past, will be able to rebuild the source code of an application if it is completely handled by autotools with similar 1-2-3 instructions (install this, install that, push the button).

Note that most users who have to (re-)build an application are not programmers, they maybe only want to configure their MIDIbox and create a new .hex file with hardware specific settings. Therefore it would be important that after a basic windows setup has been found out, some additional users without programming knowledge try to rebuilt a .hex by themself based on instructions.

Note: if the concept works, then an “all-incusive installation package” could be created.

Best Regards, Thorsten.

ptitjes · December 18, 2007, 1:27am

I don’t say your approach is too conservative! You work on this project for now more than 5 years. Project span is really big and the use cases are numerous. I think you might have seen many many recurring user questions and problems. So you are certainly at the best seat to see what could be a new issue or difficulty for your users.

As for the gpasm macro preprocessor, i’ll look whether/how/if i can extend it… I must delve more into the MBSID code and also look further into the MIOS code to see what those macro looks like. Also maybe a pre-preprocessor is possible… I won’t have to do that before January but i put that on my task list.

Anyway I like the installation package idea!

I’ll document my approach on the Wiki during this week. Then we’ll see if some users, including Windows-based, can test it! That feedback will make me figure out how to help and document with a transition scheme for those who wants to use it.

Best regards, Didier.

Narwhal · December 18, 2007, 1:53am

This seems like a good time to chime in that I’ve been having some problems following your installation instructions on OS X. I don’t have my mac with me at the moment, but I can try to post the specifics later. I started to write a detailed post yesterday, but Safari crashed when I pressed the post button grrr.

Anyway, I’m having trouble getting the configure steps for both libcmios and you other package libcan to complete. It’s not locating the pic18fregs.h file. For more detail I’ll have to try to post again when I get home. The mios-pic16-toolchain configured and installed fine for me.

$ cd ../libcmios
$ ./configure --host=pic18f4685-mios
...
<errors here>

both gputils and sdcc are installed in /usr/local/bin with libraries and headers and such located in /usr/local/share, /usr/local/share/sdcc. The file its trying to locate is in /usr/local/share/sdcc/include/pic16/

Kurt

ptitjes · December 18, 2007, 2:27am

Kurt,

There is a DEBUG=0 at the beginning of the mios-pic16-tool-wrapper script.

(It is located in /usr/bin or /usr/local/bin depending what prefix you put in the configure of mios-pic16-toolchain.)

If you put DEBUG=1 instead you’ll have the commands it really runs instead of gcc. Could you tell me what sdcc command it runs ? (Or maybe put all the output)

I do process the -I___/sdcc/lib/pic16 option so it may come from that…

Best regards, Didier.

Narwhal · December 19, 2007, 6:59pm

running configure always seems to print the same thing, so I’ve condensed it.

~/Desktop/mios-c-skeleton/libcmios-1.9f$ ./configure --host=pic18f4685-mios --prefix=/usr/local
...
...
checking for pic18fregs.h... no
configure: error: Can't compile without PIC header files
See `config.log' for more details

This is the log file:

~/Desktop/mios-c-skeleton/libcmios-1.9f$ cat config.log 
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by libcmios configure 1.9f, which was
generated by GNU Autoconf 2.61.  Invocation command line was

  $ ./configure --host=pic18f4685-mios --prefix=/usr/local

## --------- ##
## Platform. ##
## --------- ##

hostname = static-003.local
uname -m = Power Macintosh
uname -r = 8.11.0
uname -s = Darwin
uname -v = Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC

/usr/bin/uname -p = powerpc
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = Mach kernel version:
         Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC
Kernel configured for up to 2 processors.
2 processors are physically available.
Processor type: ppc7450 (PowerPC 7450)
Processors active: 0 1
Primary memory available: 2.00 gigabytes
Default processor set: 65 tasks, 188 threads, 2 processors
Load average: 0.87, Mach factor: 1.24
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /bin
PATH: /sbin
PATH: /usr/bin
PATH: /usr/sbin
PATH: /Developer/usr/bin
PATH: /usr/local/bin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:1792: checking build system type
configure:1810: result: powerpc-apple-darwin8.11.0
configure:1832: checking host system type
configure:1847: result: pic18f4685-microchip-mios
configure:1977: checking for a BSD-compatible install
configure:2033: result: /usr/bin/install -c
configure:2044: checking whether build environment is sane
configure:2087: result: yes
configure:2115: checking for a thread-safe mkdir -p
configure:2154: result: ./install-sh -c -d
configure:2167: checking for gawk
configure:2197: result: no
configure:2167: checking for mawk
configure:2197: result: no
configure:2167: checking for nawk
configure:2197: result: no
configure:2167: checking for awk
configure:2183: found /usr/bin/awk
configure:2194: result: awk
configure:2205: checking whether make sets $(MAKE)
configure:2226: result: yes
configure:2306: checking for pic18f4685-microchip-mios-strip
configure:2336: result: no
configure:2346: checking for strip
configure:2362: found /usr/bin/strip
configure:2373: result: strip
configure:2442: checking for gpasm
configure:2458: found /usr/local/bin/gpasm
configure:2470: result: gpasm
configure:2490: checking for style of include used by make
configure:2518: result: GNU
configure:2548: checking for pic18f4685-microchip-mios-gcc
configure:2578: result: no
configure:2588: checking for gcc
configure:2604: found /usr/bin/gcc
configure:2615: result: gcc
configure:2853: checking for C compiler version
configure:2860: gcc --version >&5
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5370)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:2863: $? = 0
configure:2870: gcc -v >&5
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /var/tmp/gcc/gcc-5370~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5370)
configure:2873: $? = 0
configure:2880: gcc -V >&5
gcc: argument to `-V' is missing
configure:2883: $? = 1
configure:2906: checking for C compiler default output file name
configure:2933: gcc    conftest.c  >&5
configure:2936: $? = 0
configure:2974: result: a.out
configure:2991: checking whether the C compiler works
configure:3001: ./a.out
configure:3004: $? = 0
configure:3021: result: yes
configure:3028: checking whether we are cross compiling
configure:3030: result: no
configure:3033: checking for suffix of executables
configure:3040: gcc -o conftest    conftest.c  >&5
configure:3043: $? = 0
configure:3067: result: 
configure:3073: checking for suffix of object files
configure:3099: gcc -c   conftest.c >&5
configure:3102: $? = 0
configure:3125: result: o
configure:3129: checking whether we are using the GNU C compiler
configure:3158: gcc -c   conftest.c >&5
configure:3164: $? = 0
configure:3181: result: yes
configure:3186: checking whether gcc accepts -g
configure:3216: gcc -c -g  conftest.c >&5
configure:3222: $? = 0
configure:3321: result: yes
configure:3338: checking for gcc option to accept ISO C89
configure:3412: gcc  -c -g -O2  conftest.c >&5
configure:3418: $? = 0
configure:3441: result: none needed
configure:3461: checking dependency style of gcc
configure:3552: result: gcc3
configure:3568: checking whether gcc and cc understand -c and -o together
configure:3603: gcc -c conftest.c -o conftest2.o >&5
configure:3606: $? = 0
configure:3612: gcc -c conftest.c -o conftest2.o >&5
configure:3615: $? = 0
configure:3626: cc -c conftest.c >&5
configure:3629: $? = 0
configure:3637: cc -c conftest.c -o conftest2.o >&5
configure:3640: $? = 0
configure:3646: cc -c conftest.c -o conftest2.o >&5
configure:3649: $? = 0
configure:3667: result: yes
configure:3683: checking for pic18f4685-microchip-mios-gcc
configure:3710: result: gcc
configure:3794: checking for pic18f4685-microchip-mios-as
configure:3821: result: gpasm
configure:3896: checking dependency style of gcc
configure:3987: result: gcc3
configure:4006: checking for pic18f4685-microchip-mios-ar
configure:4036: result: no
configure:4046: checking for ar
configure:4062: found /usr/bin/ar
configure:4073: result: ar
configure:4102: checking for pic18f4685-microchip-mios-ld
configure:4132: result: no
configure:4142: checking for ld
configure:4158: found /usr/bin/ld
configure:4169: result: ld
configure:4198: checking for pic18f4685-microchip-mios-ranlib
configure:4228: result: no
configure:4238: checking for ranlib
configure:4254: found /usr/bin/ranlib
configure:4265: result: ranlib
configure:4292: checking for a thread-safe mkdir -p
configure:4331: result: ./install-sh -c -d
configure:4344: checking how to run the C preprocessor
configure:4384: gcc -E  conftest.c
configure:4390: $? = 0
configure:4421: gcc -E  conftest.c
conftest.c:14:28: error: ac_nonexistent.h: No such file or directory
configure:4427: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "libcmios"
| #define PACKAGE_TARNAME "libcmios"
| #define PACKAGE_VERSION "1.9f"
| #define PACKAGE_STRING "libcmios 1.9f"
| #define PACKAGE_BUGREPORT "http://www.midibox/forum"
| #define __pic18f4685__ 1
| #define __microchip__ 1
| #define __mios__ 1
| #define PACKAGE "libcmios"
| #define VERSION "1.9f"
| #define PIC_DERIVATIVE_TYPE 4
| /* end confdefs.h.  */
| #include <ac_nonexistent.h>
configure:4460: result: gcc -E
configure:4489: gcc -E  conftest.c
configure:4495: $? = 0
configure:4526: gcc -E  conftest.c
conftest.c:14:28: error: ac_nonexistent.h: No such file or directory
configure:4532: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "libcmios"
| #define PACKAGE_TARNAME "libcmios"
| #define PACKAGE_VERSION "1.9f"
| #define PACKAGE_STRING "libcmios 1.9f"
| #define PACKAGE_BUGREPORT "http://www.midibox/forum"
| #define __pic18f4685__ 1
| #define __microchip__ 1
| #define __mios__ 1
| #define PACKAGE "libcmios"
| #define VERSION "1.9f"
| #define PIC_DERIVATIVE_TYPE 4
| /* end confdefs.h.  */
| #include <ac_nonexistent.h>
configure:4570: checking for grep that handles long lines and -e
configure:4644: result: /usr/bin/grep
configure:4649: checking for egrep
configure:4727: result: /usr/bin/grep -E
configure:4732: checking for ANSI C header files
configure:4762: gcc -c -g -O2  conftest.c >&5
configure:4768: $? = 0
configure:4864: gcc -o conftest -g -O2   conftest.c  >&5
configure:4867: $? = 0
configure:4873: ./conftest
configure:4876: $? = 0
configure:4893: result: yes
configure:4917: checking for sys/types.h
configure:4938: gcc -c -g -O2  conftest.c >&5
configure:4944: $? = 0
configure:4960: result: yes
configure:4917: checking for sys/stat.h
configure:4938: gcc -c -g -O2  conftest.c >&5
configure:4944: $? = 0
configure:4960: result: yes
configure:4917: checking for stdlib.h
configure:4938: gcc -c -g -O2  conftest.c >&5
configure:4944: $? = 0
configure:4960: result: yes
configure:4917: checking for string.h
configure:4938: gcc -c -g -O2  conftest.c >&5
configure:4944: $? = 0
configure:4960: result: yes
configure:4917: checking for memory.h
configure:4938: gcc -c -g -O2  conftest.c >&5
configure:4944: $? = 0
configure:4960: result: yes
configure:4917: checking for strings.h
configure:4938: gcc -c -g -O2  conftest.c >&5
configure:4944: $? = 0
configure:4960: result: yes
configure:4917: checking for inttypes.h
configure:4938: gcc -c -g -O2  conftest.c >&5
configure:4944: $? = 0
configure:4960: result: yes
configure:4917: checking for stdint.h
configure:4938: gcc -c -g -O2  conftest.c >&5
configure:4944: $? = 0
configure:4960: result: yes
configure:4917: checking for unistd.h
configure:4938: gcc -c -g -O2  conftest.c >&5
configure:4944: $? = 0
configure:4960: result: yes
configure:4987: checking pic18fregs.h usability
configure:5004: gcc -c -g -O2  conftest.c >&5
conftest.c:57:24: error: pic18fregs.h: No such file or directory
configure:5010: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "libcmios"
| #define PACKAGE_TARNAME "libcmios"
| #define PACKAGE_VERSION "1.9f"
| #define PACKAGE_STRING "libcmios 1.9f"
| #define PACKAGE_BUGREPORT "http://www.midibox/forum"
| #define __pic18f4685__ 1
| #define __microchip__ 1
| #define __mios__ 1
| #define PACKAGE "libcmios"
| #define VERSION "1.9f"
| #define PIC_DERIVATIVE_TYPE 4
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| /* end confdefs.h.  */
| #include <stdio.h>
| #ifdef HAVE_SYS_TYPES_H
| # include <sys/types.h>
| #endif
| #ifdef HAVE_SYS_STAT_H
| # include <sys/stat.h>
| #endif
| #ifdef STDC_HEADERS
| # include <stdlib.h>
| # include <stddef.h>
| #else
| # ifdef HAVE_STDLIB_H
| #  include <stdlib.h>
| # endif
| #endif
| #ifdef HAVE_STRING_H
| # if !defined STDC_HEADERS && defined HAVE_MEMORY_H
| #  include <memory.h>
| # endif
| # include <string.h>
| #endif
| #ifdef HAVE_STRINGS_H
| # include <strings.h>
| #endif
| #ifdef HAVE_INTTYPES_H
| # include <inttypes.h>
| #endif
| #ifdef HAVE_STDINT_H
| # include <stdint.h>
| #endif
| #ifdef HAVE_UNISTD_H
| # include <unistd.h>
| #endif
| #include <pic18fregs.h>
configure:5024: result: no
configure:5028: checking pic18fregs.h presence
configure:5043: gcc -E  conftest.c
conftest.c:24:24: error: pic18fregs.h: No such file or directory
configure:5049: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "libcmios"
| #define PACKAGE_TARNAME "libcmios"
| #define PACKAGE_VERSION "1.9f"
| #define PACKAGE_STRING "libcmios 1.9f"
| #define PACKAGE_BUGREPORT "http://www.midibox/forum"
| #define __pic18f4685__ 1
| #define __microchip__ 1
| #define __mios__ 1
| #define PACKAGE "libcmios"
| #define VERSION "1.9f"
| #define PIC_DERIVATIVE_TYPE 4
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| /* end confdefs.h.  */
| #include <pic18fregs.h>
configure:5063: result: no
configure:5096: checking for pic18fregs.h
configure:5104: result: no
configure:5116: error: Can't compile without PIC header files
See `config.log' for more details.

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=powerpc-apple-darwin8.11.0
ac_cv_c_compiler_gnu=yes
ac_cv_env_CCASFLAGS_set=
ac_cv_env_CCASFLAGS_value=
ac_cv_env_CCAS_set=
ac_cv_env_CCAS_value=
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=set
ac_cv_env_host_alias_value=pic18f4685-mios
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_header_inttypes_h=yes
ac_cv_header_memory_h=yes
ac_cv_header_pic18fregs_h=no
ac_cv_header_stdc=yes
ac_cv_header_stdint_h=yes
ac_cv_header_stdlib_h=yes
ac_cv_header_string_h=yes
ac_cv_header_strings_h=yes
ac_cv_header_sys_stat_h=yes
ac_cv_header_sys_types_h=yes
ac_cv_header_unistd_h=yes
ac_cv_host=pic18f4685-microchip-mios
ac_cv_objext=o
ac_cv_path_EGREP='/usr/bin/grep -E'
ac_cv_path_GREP=/usr/bin/grep
ac_cv_path_install='/usr/bin/install -c'
ac_cv_prog_AS=gpasm
ac_cv_prog_AWK=awk
ac_cv_prog_CC=gcc
ac_cv_prog_CPP='gcc -E'
ac_cv_prog_ac_ct_AR=ar
ac_cv_prog_ac_ct_CC=gcc
ac_cv_prog_ac_ct_LD=ld
ac_cv_prog_ac_ct_RANLIB=ranlib
ac_cv_prog_ac_ct_STRIP=strip
ac_cv_prog_cc_c89=
ac_cv_prog_cc_g=yes
ac_cv_prog_cc_gcc_c_o=yes
ac_cv_prog_make_make_set=yes
am_cv_CCAS_dependencies_compiler_type=gcc3
am_cv_CC_dependencies_compiler_type=gcc3

## ----------------- ##
## Output variables. ##
## ----------------- ##

ACLOCAL='${SHELL} /Users/kurtarnlund/Desktop/mios-c-skeleton/libcmios-1.9f/missing --run aclocal-1.10'
AMDEPBACKSLASH='\'
AMDEP_FALSE='#'
AMDEP_TRUE=''
AMTAR='${SHELL} /Users/kurtarnlund/Desktop/mios-c-skeleton/libcmios-1.9f/missing --run tar'
AR='ar'
AS='gpasm'
AUTOCONF='${SHELL} /Users/kurtarnlund/Desktop/mios-c-skeleton/libcmios-1.9f/missing --run autoconf'
AUTOHEADER='${SHELL} /Users/kurtarnlund/Desktop/mios-c-skeleton/libcmios-1.9f/missing --run autoheader'
AUTOMAKE='${SHELL} /Users/kurtarnlund/Desktop/mios-c-skeleton/libcmios-1.9f/missing --run automake-1.10'
AWK='awk'
CC='gcc'
CCAS='gcc'
CCASDEPMODE='depmode=gcc3'
CCASFLAGS='-g -O2'
CCDEPMODE='depmode=gcc3'
CFLAGS='-g -O2'
CPP='gcc -E'
CPPFLAGS=''
CYGPATH_W='echo'
DEFS=''
DEPDIR='.deps'
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP='/usr/bin/grep -E'
EXEEXT=''
GREP='/usr/bin/grep'
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='$(install_sh) -c -s'
LD='ld'
LDFLAGS=''
LIBOBJS=''
LIBS=''
LTLIBOBJS=''
MAKEINFO='${SHELL} /Users/kurtarnlund/Desktop/mios-c-skeleton/libcmios-1.9f/missing --run makeinfo'
OBJEXT='o'
PACKAGE='libcmios'
PACKAGE_BUGREPORT='http://www.midibox/forum'
PACKAGE_NAME='libcmios'
PACKAGE_STRING='libcmios 1.9f'
PACKAGE_TARNAME='libcmios'
PACKAGE_VERSION='1.9f'
PATH_SEPARATOR=':'
RANLIB='ranlib'
SET_MAKE=''
SHELL='/bin/sh'
STRIP='strip'
VERSION='1.9f'
ac_ct_CC='gcc'
ac_default_prefix='/usr/pic18f4685-microchip-mios'
ac_tool_prefix='pic18f4685-microchip-mios-'
am__fastdepCCAS_FALSE='#'
am__fastdepCCAS_TRUE=''
am__fastdepCC_FALSE='#'
am__fastdepCC_TRUE=''
am__include='include'
am__isrc=''
am__leading_dot='.'
am__quote=''
am__tar='${AMTAR} chof - "$$tardir"'
am__untar='${AMTAR} xf -'
bindir='${exec_prefix}/bin'
build='powerpc-apple-darwin8.11.0'
build_alias=''
build_cpu='powerpc'
build_os='darwin8.11.0'
build_vendor='apple'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
dvidir='${docdir}'
exec_prefix='NONE'
host='pic18f4685-microchip-mios'
host_alias='pic18f4685-mios'
host_cpu='pic18f4685'
host_linker_script='pic18f4685.lkr'
host_os='mios'
host_vendor='microchip'
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
install_sh='$(SHELL) /Users/kurtarnlund/Desktop/mios-c-skeleton/libcmios-1.9f/install-sh'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${datarootdir}/man'
mkdir_p='$(top_builddir)/./install-sh -c -d'
oldincludedir='/usr/include'
pdfdir='${docdir}'
prefix='/usr/local'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias=''

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_NAME "libcmios"
#define PACKAGE_TARNAME "libcmios"
#define PACKAGE_VERSION "1.9f"
#define PACKAGE_STRING "libcmios 1.9f"
#define PACKAGE_BUGREPORT "http://www.midibox/forum"
#define __pic18f4685__ 1
#define __microchip__ 1
#define __mios__ 1
#define PACKAGE "libcmios"
#define VERSION "1.9f"
#define PIC_DERIVATIVE_TYPE 4
#define STDC_HEADERS 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRING_H 1
#define HAVE_MEMORY_H 1
#define HAVE_STRINGS_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_STDINT_H 1
#define HAVE_UNISTD_H 1

configure: exit 1

I hope it’s just that I’m doing something stupid.

Kurt

ptitjes · December 20, 2007, 9:26am

Sorry Narwhal,

I overlooked your post and didn’t see that you did not pass the configure step. It seems that mios-pic16-toolchain did not install so well.

Explanation: Your config.log says it does not find pic18f4685-microchip-mios-gcc:

configure:2548: checking for pic18f4685-microchip-mios-gcc
configure:2578: result: no
configure:2588: checking for gcc
configure:2604: found /usr/bin/gcc
configure:2615: result: gcc
configure:2853: checking for C compiler version
configure:2860: gcc --version >&5
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5370)

Explanation continued: sdcc adds automatically its own include directory (containing amongst others pic18fregs.h), which standard gcc (here powerpc-apple-darwin8-gcc) hopefully does not. So could you please tell me what exact configure parameters you gave to mios-pic16-toolchain. What is the prefix you gave ? Did you put ‘/usr’ or ‘/usr/local’ ? And also what were the output ??

~/Desktop/mios-c-skeleton/mios-pic16-toolchain/$ ./configure --target=pic18f4685-mios --prefix=/usr
~/Desktop/mios-c-skeleton/mios-pic16-toolchain/$ sudo make install

I would like to understand where it installed the toolchain. Could you verify if ${prefix}/bin/pic18f4685-microchip-mios-gcc exists ?

$ echo $PATH
$ which pic18f4685-microchip-mios-gcc
$ ls -l /usr/local/bin/pic18f4685-microchip-mios-gcc
$ ls -l /usr/bin/pic18f4685-microchip-mios-gcc

Thank you.

Best regards,

Didier.

ptitjes · December 20, 2007, 5:20pm

Starting some documentation : http://www.midibox.org/dokuwiki/howto:dev:autotools-skeleton

Cheers, Didier.

Narwhal · December 20, 2007, 6:20pm

Hi Didier,

Yeah the it seems my problem crept in when I decided that I want the gpasm, sdcc, and mios tool chain files in my /usr/local/bin. In my learning how to do that I think I screwed things up. I’m not yet sure why or how, but all of links that are created (to pic18f4685-microchip-mios-gcc, etc) were sitting in my /src directory and were never moved to /usr/local/bin. In fact, it seems that make uninstall does not remove these files. I tried “$sudo make uninstall” and that didn’t work. I think I forgot the sudo command once and ran the make install without the permissions. Then it made all the files, but could not copy them to the destination. So I was stuck in limbo, with it unable to back up and try again, because nothing would clean up the /src directory if it couldn’t find the files in the destination (/usr/local/bin).

So I moved/created the links pic18f4685-microchip-mios-gcc, -ar, -as, -ld, -ranlib in /usr/local/bin and the tool chain looks like it’s set up correctly now.

/usr/local/bin$ls
... gpasm and sdcc files here ...
...
-rwxr-xr-x    1 root  wheel    2624 Dec 20 09:55 mios-fixasm.pl
-rwxr-xr-x    1 root  wheel    5226 Dec 20 09:58 mios-pic16-tool-wrapper
...
lrwxr-xr-x    1 root  wheel      23 Dec 20 10:03 pic18f4685-microchip-mios-ar -> mios-pic16-tool-wrapper
lrwxr-xr-x    1 root  wheel      23 Dec 20 10:04 pic18f4685-microchip-mios-as -> mios-pic16-tool-wrapper
lrwxr-xr-x    1 root  wheel      23 Dec 20 10:04 pic18f4685-microchip-mios-gcc -> mios-pic16-tool-wrapper
lrwxr-xr-x    1 root  wheel      23 Dec 20 10:04 pic18f4685-microchip-mios-ld -> mios-pic16-tool-wrapper
lrwxr-xr-x    1 root  wheel      23 Dec 20 10:04 pic18f4685-microchip-mios-ranlib -> mios-pic16-tool-wrapper

is this the correct setup? before I attempt to configure libcmios? Still getting errors configuring libcmios, but it’s definitely seems to be working better (ie: using the correct compiler now)

~/Desktop/mios-autotools-skeleton/libcmios-1.9f$ ./configure --host=pic18f4685-mios --prefix=/usr/local
configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
checking build system type... powerpc-apple-darwin8.11.0
checking host system type... pic18f4685-microchip-mios
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking for pic18f4685-microchip-mios-strip... no
checking for strip... strip
checking for gpasm... gpasm
checking for style of include used by make... GNU
checking for pic18f4685-microchip-mios-gcc... pic18f4685-microchip-mios-gcc
checking for C compiler default output file name... 
configure: error: C compiler cannot create executables
See `config.log' for more details.

Thanks for all the help,

Kurt