Hi! We've been using something relatively ugly in cudaPackages because the "cuda compiler driver" usually needs an old gcc, but the libraries it produces need to co-exist with the normal nixpks shared libraries in the same process, and so they need to link against the same c++ standard library. It's like with clang using libstdc++, only the old gcc in place of clang.

I now consider using this uglyness outside cudaPackages because e.g. tensorflow also has some ideas about which compilers it's compatible with. I was suggested that instead of introducing new attributes or changing the meaning of attributes like gccXXStdenv I write a "stdenv adapter".

The hack is (ab)using wrapCCWith with gccForLibs. One bit I'm unsure of is whether I should pass wrapCC the target stdenv's wrapped cc, or the unwrapped one: https://github.com/NixOS/nixpkgs/pull/275947/commits/30016f9c4622fca0145e9904f471079e9393eff1#diff-cea9c91ed8344102b5d5fbf28eae400b8182d3b51d718f88345de8c7a187165fR243

We've been using the unwrapped one so far (because it didn't matter), but I wonder if discarding the old wrappers flags&c is the right thing to do in the general case? This suggests the 2nd question, do wrapCCs compose?

Hey everyone.

Have been working on getting qtbase and qtmultimedia cross compiling for windows.
See
https://github.com/NixOS/nixpkgs/issues/274274
https://github.com/NixOS/nixpkgs/issues/272538
https://github.com/seanybaggins/qt-package-overalys

I got an example application cross compiling to windows. You can reproduce my results by doing the following

git clone https://github.com/seanybaggins/qt-package-overalys
nix build '.#pkgs.pkgsCross.qtapp-example
nix copy ../releases/qtapp-example '.#pkgs.pkgsCross.mingw32.qtapp-example' --no-check-sigs
cd ../releases/qtapp-example
mkdir staging
cp -r --dereference ./nix/store/<hash>-qtapp-example-i686-w64-mingw32-6.5.1/bin/* staging

# run inno setup. I used bottes to run it on linux. This is the iss file that I made to do the build
; Script generated by the Inno Setup Script Wizard.
; SEE THE DOCUMENTATION FOR DETAILS ON CREATING INNO SETUP SCRIPT FILES!

#define MyAppName "My Program"
#define MyAppVersion "1.5"
#define MyAppPublisher "My Company, Inc."
#define MyAppURL "https://www.example.com/"
#define MyAppExeName "untitled.exe"

[Setup]
; NOTE: The value of AppId uniquely identifies this application. Do not use the same AppId value in installers for other applications.
; (To generate a new GUID, click Tools | Generate GUID inside the IDE.)
AppId={{89681292-40F7-4D19-952B-8D51D68A6FC8}
AppName={#MyAppName}
AppVersion={#MyAppVersion}
;AppVerName={#MyAppName} {#MyAppVersion}
AppPublisher={#MyAppPublisher}
AppPublisherURL={#MyAppURL}
AppSupportURL={#MyAppURL}
AppUpdatesURL={#MyAppURL}
DefaultDirName={autopf}\{#MyAppName}
DisableDirPage=yes
DisableProgramGroupPage=yes
; Uncomment the following line to run in non administrative install mode (install for current user only.)
;PrivilegesRequired=lowest
OutputBaseFilename=mysetup
Compression=lzma
SolidCompression=yes
WizardStyle=modern

[Languages]
Name: "english"; MessagesFile: "compiler:Default.isl"

[Tasks]
Name: "desktopicon"; Description: "{cm:CreateDesktopIcon}"; GroupDescription: "{cm:AdditionalIcons}"; Flags: unchecked

[Files]
Source: "Z:\<your-path>\releases\qtapp-example\staging\{#MyAppExeName}"; DestDir: "{app}"; Flags: ignoreversion
Source: "Z:\<your-path>\releases\qtapp-example\staging\*"; DestDir: "{app}"; Flags: ignoreversion recursesubdirs
; NOTE: Don't use "Flags: ignoreversion" on any shared system files

[Icons]
Name: "{autoprograms}\{#MyAppName}"; Filename: "{app}\{#MyAppExeName}"
Name: "{autodesktop}\{#MyAppName}"; Filename: "{app}\{#MyAppExeName}"; Tasks: desktopicon

As you can see, there were some lingering steps that I needed to run so I could get rid of symlinks and then run inno setup. Was wondering if some changes could be made within stdenv so I have an option to deference symbolic links within my derivation.

In reply to @ss:someonex.net

Hi! We've been using something relatively ugly in cudaPackages because the "cuda compiler driver" usually needs an old gcc, but the libraries it produces need to co-exist with the normal nixpks shared libraries in the same process, and so they need to link against the same c++ standard library. It's like with clang using libstdc++, only the old gcc in place of clang.

I now consider using this uglyness outside cudaPackages because e.g. tensorflow also has some ideas about which compilers it's compatible with. I was suggested that instead of introducing new attributes or changing the meaning of attributes like gccXXStdenv I write a "stdenv adapter".

The hack is (ab)using wrapCCWith with gccForLibs. One bit I'm unsure of is whether I should pass wrapCC the target stdenv's wrapped cc, or the unwrapped one: https://github.com/NixOS/nixpkgs/pull/275947/commits/30016f9c4622fca0145e9904f471079e9393eff1#diff-cea9c91ed8344102b5d5fbf28eae400b8182d3b51d718f88345de8c7a187165fR243

We've been using the unwrapped one so far (because it didn't matter), but I wonder if discarding the old wrappers flags&c is the right thing to do in the general case? This suggests the 2nd question, do wrapCCs compose?

Heeey a new question: wrapCCWith takes a coreutils, and now should one manually pass buildPackages.coreutils to wrapCCWith, or should one call buildPackages.wrapCCWith or does this look like I made a terrible mistake early on and this question should never have arisen?

Context: https://github.com/NixOS/nixpkgs/pull/281371

In reply to @connorbaker:matrix.org
I mean, stdenv.cc.coreutils_bin seems to always be correct, so you could just take it from there