Multiple definition of _isatty

Sysprogs forums Forums VisualGDB Multiple definition of _isatty

This topic contains 8 replies, has 2 voices, and was last updated by  support 3 months, 2 weeks ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #13365

    JoeWright
    Participant

    Hi, I’ve just created a new project, importing from CubeMX and I’ve got a conflict.

    With Fast Semihosting enabled, I get a multiple definition for _isatty, one in syscalls.c and one in FastSemihosting.cpp

    Perhaps I have some things set up incorrectly.  It seems there’s been an update, as I don’t remember the option to import directly from STM32CubeMX.  And I noticed that, whereas before I was including various frameworks, this time that just doubles up everything as its already coming through on the import.

    Thanks for any help,
    Joe

    #13370

    support
    Keymaster

    Hi,

    If you would like to use fast semihosting, you would need to remove other implementations of the low-level I/O functions from the project. The default implementations from the toolchain shipped with VisualGDB are marked as weak, so they will be automatically replaced by the fast semihosting ones (when enabled), however if your project provides different implementations (in syscalls.c?) please try excluding them from the project (if you are using the GNU ARM toolchain, please disable regular semihosting on the first page of VisualGDB Project Properties).

    #13371

    JoeWright
    Participant

    Thanks for the reply.  I’m not deliberately avoiding the VisualGDB toolchain, and in fact this all worked fine in my last project.  I’m just wondering if the new function of importing from STM32CubeMX is doing something strange.  I’ve ticked ‘Add necessary library files as reference in the toolchain project configuration file’ in cubemx but the project file seems to be pointing to Cubemx versions (c:\users\joe\stm32cube…) rather than visualgdb.

    When I added the stm32f3cube hal it created a lot of conflicts.  So it would appear that cubemx is producing references differently than in previous projects?  I’ve copied to the cubemx project file from before so have only made minimal changes.  Not sure why things are behaving differently.  I can only see the new import option as a change from before.

    #13372

    JoeWright
    Participant

    I guess using the new import option, the firmware location needs to be specified.  But the folder structure for STM32CubeMX (…\Repository\STM32Cube_FW_F3_V1.9.0) is somewhat different to the visualGDB one (…\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\STM32F3xxxx\).

    So I’m not sure what to put in there.

    #13374

    support
    Keymaster

    Hi,

    The conflicts between files would likely be caused by VisualGDB referencing its own frameworks (e.g. STM32 HAL). If you are using the latest VisualGDB 5.3 with the new automatic STM32CubeMX importer as described here, it should not happen. If it does, could you please upload the project generated by STM32CubeMX and the project imported by VisualGDB and post a link here so that we could see what is going on?

    You can also just remove the references to the VisualGDB version of the HAL via VisualGDB Project Properties -> Embedded Frameworks.

    #13376

    JoeWright
    Participant

    Hi, yes that’s what’s happening.  I’ll try and upload a bit later.

    My temporary solution was to remove the embedded framework references as you said, but then I ran into that problem with the Fast Semihosting framework as it was conflicting with the cubemx refs for _isatty

    #13377

    support
    Keymaster

    Hi,

    That would be normal if the imported code provides its own I/O functions. The linker usually mentions both source files defining the conflicting function in the error message, so you can simply locate the one coming from CubeMX and remove it from the project.

    #13381

    JoeWright
    Participant

    Hi, the problem is that with the new gpdsc importer, it guarantees you’re going to get conflicts.  The solution is to remove all the cubemx sources and headers referenced in the generated project, delete the include folder additions in the project settings, and enable the embedded frameworks in visualgdb.

    That is more work than it used to be, when using the import from source files, adding the inc folder, and selecting the choice of embedded frameworks.

    Attached is an example of an imported project (along with the cubemx base.ioc and base.gpdsc files).  The only other thing I did was enable the Fast Semihosting, which gives rise to the clash with _isatty.

    I think if the gpdsc importer is going to be useful, it needs to detect and override the sources of the embedded frameworks coming from cubemx.  Or is there something that can be put in for the alternative firmware location in cubemx?  As I see it, cubemx firmware and visualgdb firmware use different folder structures so I’m not sure what I would put in that field.

    Thanks, Joe

    Attachments:
    You must be logged in to view attached files.
    #13385

    support
    Keymaster

    Hi,

    Thanks for attaching the project. The new STM32CubeMX importer actually does exactly what you are describing – it explicitly removes references to the STM32 HAL installed by VisualGDB so that the project can use the version from STM32CubeMX.

    The project you attached doesn’t build because you have both the regular and the advanced semihosting enabled at the same time. Please disable the regular semihosting as shown below:

    • This reply was modified 3 months, 2 weeks ago by  support.
    Attachments:
    You must be logged in to view attached files.
Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.