dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.85k stars 4.62k forks source link

NativeAOT generates native object without correct prefix #102869

Open JCash opened 3 months ago

JCash commented 3 months ago

Description

When I generate static libraries using NativeAOT for macOS, it doesn't produce a standard name. (With standard, I mean gcc/clang) For feature.csproj, it will output feature.a. The expected name is libfeature.a

With more projects using NativeAOT, I think fixing this will be very beneficial, since the non-standard naming scheme will require workarounds in most common toolchains.

Relevant code: https://github.com/dotnet/runtime/blob/36a85b00695007652d8a2d5e1c5e9d99b7247505/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.targets#L82C65-L82C80

Compare with LibraryBuilder.cs, which does seem to support it: https://github.com/dotnet/runtime/blob/36a85b00695007652d8a2d5e1c5e9d99b7247505/src/tasks/LibraryBuilder/LibraryBuilder.cs#L413

Reproduction Steps

I use a NativeAOT project feature.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <PublishAot>true</PublishAot>
    <AllowUnsafeBlocks>True</AllowUnsafeBlocks>
    <StackTraceSupport>true</StackTraceSupport>
    <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
    <AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
  </PropertyGroup>
</Project>

I build the project with

dotnet publish -r osx-arm64 -p:PublishAot=true -p:NativeLib=Static feature.csproj

Expected behavior

For *nix platforms, I expect the static libraries to have a prefix lib in order for them to work as usual with gcc/clang.

Actual behavior

The static libraries for *nix platforms are missing the prefix. A feature.csproj will output a feature.a file.

Regression?

No response

Known Workarounds

Passing libraries to the compiler using an absolute path. Requires more heavy lifting to support in different build toolchains.

Configuration

No response

Other information

No response

dotnet-policy-service[bot] commented 3 months ago

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas See info in area-owners.md if you want to be subscribed.

am11 commented 3 months ago

You can set this property in your project: <TargetName>libfeature</TargetName> for both Static and Shared libs. (also works for executables)

We generally follow the native toolchain convention, which in this case will produce a.out (for libs and executables alike), unless -o is provided. We just default to project name.

JCash commented 3 months ago

Hi @am11 !

Thanks for the suggestion! Do you know, is it possible to have <TargetName>libfeature</TargetName> for *nix platforms and <TargetName>feature</TargetName> for windows, in the same .csproj file?

am11 commented 3 months ago

Something like:

<TargetName>$(MSBuildProjectName)</TargetName>
<TargetName Condition="'$(OS)' != 'Windows_NT'">lib$(TargetName)</TargetName>
JCash commented 3 months ago

Thanks! That works for my use case.