Multiple definition of _isatty

[JoeWright]

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

[support]

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).

[JoeWright]

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.

[JoeWright]

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.

[support]

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.

[JoeWright]

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

[support]

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.

[JoeWright]

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.

[support]

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 6 years, 10 months ago by support.

Attachments:

You must be logged in to view attached files.

[Author]

Posts