#1512 build pic specific libs as specific

closed-fixed
nobody
5
2013-05-25
2009-03-02
Don Wooton
No

warning: processor mismatch in "pic16f688.o"

Although it is probably not a problem to compile all
of the PIC specific libraries as a single PIC type, creating them correctly takes no longer and is a big step closer to not needing the --processor-mismatch option.

During the build of sdcc, both the pic14 and pic16 ports pass
correct followed by incorrect -p$(ARCH) options to sdcc when
making the PIC specific libraries.

You can see this by inspecting the log from a command similar to this:
make Q= SILENT=Y -C sdcc 2>&1 | tee build.log

By moving the default options such as
CFLAGS += -mpic14 -p16f$(ARCH)
out of the common Makefiles and into the individual Makefiles we
gain better control and aviod conflicting values.

The attached patch is one way to do this.
It applies to svn r5404. It is long due to the repeats; but is rather simple.
For clarity I attempted to keep the -m and -p options together.

- Don

Discussion

  • Don Wooton
    Don Wooton
    2009-03-02

    processor_mismatch.patch

     
  • Raphael Neider
    Raphael Neider
    2009-03-02

    Simpler patch for the pic14 libdev/ tree

     
  • Raphael Neider
    Raphael Neider
    2009-03-02

    I agree with you that the pic14 build system is sub-optimal and I didn't even know that the libdev/ tree was built for the default device (16f877). I would propose a simpler fix (attached) to address this issue, and rely on the undocumented SDCC feature of taking the *first* -pPROCESSOR option and ignoring all following ones (as done for the pic16 library). This should and will be fixed, probably after the 2.9.0 release, i.e., in early April 2009.

    @Borut: The patch is simple enough to be included in 2.9.0 at your discretion.

    As libsdcc.lib is still built for the 16f877 and probably used in most projects (for generic pointer and initialized global/static data), the warning would remain. So there is not much to be gained here, is there?

    For the major part of your patch, addressing the pic16 port, I fail to see the problem: We call
    sdcc -p<whatever> -mpic16 -p18f452, and as the first -p option wins, the pic16 libdev/ tree is already built correctly. I admit, using -mpic16 from the configure-time environment is more than just confusing, but as long as it works I do not feel too inclined to touch this. Some day, the -mpic16 -p@ARCH@ options should be added to AM_CFLAGS in Makefile.common, but as this does not need to be fixed right now, I won't do it (unless convinced otherwise).

    Hoping that you can live with the proposed course of action and thankful for the hint on the broken pic14 libdev/ build system,
    Raphael
    File Added: simple-fix-pic14.patch

     
  • Raphael Neider
    Raphael Neider
    2009-03-02

    • status: open --> open-later
     
  • Don Wooton
    Don Wooton
    2009-03-02

    I am happy with your call on this. Thank you.

     
  • Borut Ražem
    Borut Ražem
    2009-03-03

    Raphael, please go ahead and commit the patch.

    Borut

     
  • Raphael Neider
    Raphael Neider
    2009-03-03

    • milestone: --> fixed
    • status: open-later --> closed-fixed
     
  • Raphael Neider
    Raphael Neider
    2009-03-03

    Fixed in r5405 using simple-fix-pic14.patch.