Problem building on Arch Linux: min/max not defined

[tetious]

When trying to build the rc2 branch OR master on Arch Linux (clang 3.8) I get numerous build failures due to missing min and max macros.

Example: mbstring.cpp:182:20: error: use of undeclared identifier 'min'

I'm assuming they are supposed to be defined in a platform include somewhere, and there is some voodoo I don't understand happening between pal.h (where I see them defined) and palinternal.h that seems to be excluding your local copy. Or something. Sorry, I'm a bit out of my depth here, as I only know enough C++/C to get into trouble. :)

Anyway, I was able to get things building by copying the defines for min and max from pal.h to palinternal.h. (above the include guard) I'm reasonably sure this was not the correct thing to do, even though it "worked," but I'm not certain what is going wrong with the build configure process that causes this.

Hopefully I've given enough information here to identify what I might be doing wrong, or if maybe there is a problem with the build scripts.

[davzucky]

I have been able to build CoreClr on ArchLinux using clang 3.5. Could you try to use that version ? I will try to update it on my side to see if I have the same problem. Be aware that you wont be able to build mscorelib because of some post build step that download a cli package which was generate for ubuntu.

[janvorli]

@tetious - It seems that the macro definitions in the pal.h can be moved out of the #ifndef PAL_STDCPP_COMPAT and defined conditionally like this:

#ifndef max
#define max(a, b) (((a) > (b)) ? (a) : (b))
#endif
#ifndef min
#define min(a, b) (((a) < (b)) ? (a) : (b))
#endif

I believe that should fix the issue.

[tetious]

@davzucky I did try building with clang 3.5 and ran into the same problem. I'm pretty sure I tried it based on your mention of success elsewhere. Not sure why it worked for you and not me. :)

@janvorli That didn't seem to fix it. I'm not sure why. I even tried putting them outside the include guard. The only way I've been able to get a successful build is by putting them outside the include guard in palinternal.h.

Also, I needed to apply the fix here, which maybe could be cherry-picked into this branch? https://github.com/dotnet/coreclr/pull/4433

[davzucky]

@tetious, After updating my fork, I'm now getting the same problem as you. This is confusing as the save branch is working on Ubuntu. I'm not sure what could cause the problem and min max definition in palinternal doesnt sound right. I will try to go through all the change on the build script that could have trigger that for the past 2-3 weeks. Let me know if you find anything.

@janvorli, Any idea what could trigger this error on one distribution but not on other ? I know it use to work on the same machine before I rebase my fork which was old of ~2-3 weeks

[janvorli]

@davzucky, @tetious is it possible that the issue is not related to our source changes, but rather to some update of your Linux? E.g. that the min / max macros would be removed from some header files that we are including, possibly moved somewhere else? These macros are not required to exist by the C++ standard. Could you scan all headers on your Linux to see where (if at all) the macro is defined?

[seanshpark]

For me, it's defined at 'coreclr/src/pal/inc/pal.h' file, line 6067

#define max(a, b) (((a) > (b)) ? (a) : (b))
#define min(a, b) (((a) < (b)) ? (a) : (b))

#endif // !PAL_STDCPP_COMPAT

and I think PAL_STDCPP_COMPAT is not defined for the build, but I can find them in some .cmake files.

[janvorli]

I am sorry for not being clear, I meant where is it defined in the system headers, not in our ones. The PAL_STDCPP_COMPAT is defined when building several components (debugger stuff / lttng stuff).

[tetious]

Here is the result of a grep in /usr/include on my system:

./X11/Xlibint.h-
./X11/Xlibint.h:#define min(a,b) (((a) < (b)) ? (a) : (b))
./X11/Xlibint.h-#define max(a,b) (((a) > (b)) ? (a) : (b))
./X11/Xlibint.h-

./clang/Basic/SourceManager.h-/// Given an example of:
./clang/Basic/SourceManager.h-/// \code
./clang/Basic/SourceManager.h:/// #define min(x, y) x < y ? x : y
./clang/Basic/SourceManager.h-/// \endcode
./clang/Basic/SourceManager.h-///

./python2.7/TiffDecode.h-
./python2.7/TiffDecode.h-#ifndef min
./python2.7/TiffDecode.h:#define min(x,y) (( x > y ) ? y : x )
./python2.7/TiffDecode.h-#define max(x,y) (( x < y ) ? y : x )
./python2.7/TiffDecode.h-#endif

I think it is interesting that the only clang result is an example. :)

It does look like it isn't defined anywhere that would reasonably be included.

[janvorli]

Ok, so that would explain why it was not found if the PAL_STDCPP_COMPAT was not defined, since in that case, we don't try to define the min and max. So I wonder if you are hitting the error while building the components that have the PAL_STDCPP_COMPAT defined. Would you mind sharing the build log so that I can take a peek?

[davzucky]

@tetious and @janvorli, I think I found the root cause and as you say @Janvorli this is a system problem relate to the update of the gcc package on my system. As Linux is a rolling like type of system it can be hurd by this type of problem earlier. I ran the below command to downgrad gcc and gcc-lib from 6.1.1.1 to 5.3.0.5 and I'm now able to build again.

sudo pacman -U https://archive.archlinux.org/packages/g/gcc/gcc-5.3.0-5-x86_64.pkg.tar.xz https://archive.archlinux.org/packages/g/gcc-libs/gcc-libs-5.3.0-5-x86_64.pkg.tar.xz

I will have to look at what is the delta in these packages tomorrow to see what got broken. @tetious, Could you try to downgrade the library as well to confirm it's working as well for you ?

[davzucky]

BTW, I had as well to downgrade LLVM to get it working as the new version is build against GCC 6. Run this command as well

sudo pacman -U https://archive.archlinux.org/packages/l/llvm/llvm-3.7.1-1-x86_64.pkg.tar.xz https://archive.archlinux.org/packages/l/llvm-libs/llvm-libs-3.7.1-1-x86_64.pkg.tar.xz

my build still hasn't finished but it's moving forward :-). need to find what change in GCC

[ghost]

@juergenhoetzel, @vindicatorr, did you guys experience this error?

[elangelo]

Downgrading gcc, gcclibs and llvm didn't work for me. The suggestion of @janvorli didn't work for me. But after adding that (*) to palinternal.h the compile seem to work fine.

(*)

ifndef max

#define max(a, b) (((a) > (b)) ? (a) : (b))
#endif
#ifndef min
#define min(a, b) (((a) < (b)) ? (a) : (b))
#endif

https://github.com/elangelo/coreclr/tree/pal

[juergenhoetzel]

min/max is not defined in the standard C Headers. It's only defined in stdlibc++: http://www.cplusplus.com/reference/algorithm/max/

The libstdc++ devs actually undefine min/max to prevent conflicts

See /PATH_TO_CPP_INCLUDES/bits/c++config.h:

// For example, <windows.h> is known to #define min and max as macros...
#undef min
#undef max

You can check this using this C++ code:

#define max( a, b ) (((a) > (b)) ? (a) : (b))
#include <iostream>
int main(int argc, char **argv)  {
std::cout << max(1,2) << std::endl;
}

results in

/tmp/test.cc:4:15: error: use of undeclared identifier 'max'; did you mean 'std::max'?
        std::cout << max(1,2) << std::endl;
                     ^~~
                     std::max

There is also Bugreport of #undef min/max is dependent on order if #include

The root cause of this problem is that recent versions of libstdc++ provide their own wrappers for stdlib.h:

Thus the GLIBC header /usr/include/stdlib.h (which didn't undefine min/max) isn't used anymore.

I added a woraround in my branch https://github.com/dotnet/coreclr/commit/7864b05cfcf16b1261962c5538e2f071759a1d9e

to restore the old behavior.

Seems Arch Linux is the first distro using GCC6. But this will also hit Fedora 24.

[vindicatorr]

@jasonwilliams200OK I was out of town, but was just about to do a full rebuild for a different corefx bug and encountered this issue. (posted on gitter)

[  1%] Building CXX object src/pal/src/CMakeFiles/coreclrpal.dir/cruntime/mbstring.cpp.o
.../tmp/source/coreclrarch/src/pal/src/cruntime/mbstring.cpp:182:20: error: use of undeclared identifier 'min'
            ret += min(count, strlen((const char*)string));
                   ^
1 error generated.
src/pal/src/CMakeFiles/coreclrpal.dir/build.make:182: recipe for target 'src/pal/src/CMakeFiles/coreclrpal.dir/cruntime/mbstring.cpp.o' failed
make[2]: *** [src/pal/src/CMakeFiles/coreclrpal.dir/cruntime/mbstring.cpp.o] Error 1
CMakeFiles/Makefile2:241: recipe for target 'src/pal/src/CMakeFiles/coreclrpal.dir/all' failed
make[1]: *** [src/pal/src/CMakeFiles/coreclrpal.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[  1%] Building CXX object src/corefx/System.Globalization.Native/CMakeFiles/System.Globalization.Native.dir/normalization.cpp.o

[juergenhoetzel]

I was able to build on Arch Linux (clang3.5 + clang3.8) using my workaround: https://github.com/dotnet/coreclr/issues/5006#issuecomment-222191925

I just updated my branch (there was an invalid CPP-conditional).

[ghost]

Thanks for the fix @judemelancon! Can you send a pull request so this matter is resolved once and for all. :)

[judemelancon]

@jasonwilliams200OK @juergenhoetzel This is just to make sure your conversation isn't derailed by that overzealous autocompletion.

[vindicatorr]

I'm pretty sure I've done some cherry-picking once or twice before, but maybe I'm doing it wrong now because I get "fatal: bad object 7864b05cfcf16b1261962c5538e2f071759a1d9e"

I'm on coreclr's master branch and just trying a simple "git cherry-pick 786...", even after cleaning, resetting, fetching and pulling. I must be missing something.

[ghost]

@judemelancon, sorry I meant to @ juergenhoetzel. :smile:

[ghost]

@vindicatorr, this is becasue the code is not in dotnet repo yet. GitHub can show you the unavailable commit in the URL from the fork even before it is merged. To cherry-pick commit from @juergenhoetzel's branch:

cd coreclr # your fork

# change branch to your master
git checkout master

# add remote for dotnet
git remote add dotnet https://github.com/dotnet/coreclr

# fetch dotnet remote
git fetch dotent

# rebase with dotnet remote
git pull --rebase dotnet master # or simply git reset --hard dotnet/master

# add remote for Jürgen's fork
git remote add  juergenhoetzel https://github.com/juergenhoetzel/coreclr 

# fetch Jürgen's remote
git fetch juergenhoetzel

# cherry-pick the desired commit
git cherry-pick 7864b05

[vindicatorr]

@jasonwilliams200OK I'm still having a problem getting the commit:

... (tried with rebase and reset --hard)
$ git cherry-pick 7864b05
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
You are currently cherry-picking commit 7864b05.

nothing to commit, working directory clean
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git reset'

I did adjust for the misspelled "dotent" and did the "git config" that it told me to do. I had/have no intention of "pushing".

[ghost]

@vindicatorr, you can start over by running git reset --hard dotnet/master followed by the last three steps from my prev comment. That would get you there.

If you don't want to cherry-pick, you can simply clone @juergenhoetzel's branch:

git clone https://github.com/juergenhoetzel/coreclr -b LIBSTDC++_STDLIB_WORKAROUND j-coreclr

cd j-coreclr

./build.sh

[davzucky]

@juergenhoetzel Thank you very much for the fix. I tested and I'm able to get the build on Arch Linux working again. Where I'm confused is that when I look at the header between gcc5.3 and gcc6.1 I can see that min and max was already undefine in /PATH_TO_CPP_INCLUDES/bits/c++config.h. What am I missing here ? As well how did you find this exclusion attribute. Any tips to find them ?

[vindicatorr]

Weird, don't know why it worked after doing that reset "again" (since it's already step 5).

But the build fails later on now. Don't know if a new bug should be created:

[ 69%] Linking CXX executable eventprovidertest
/usr/bin/ld: warning: liburcu-bp.so.2, needed by /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: liburcu-cds.so.2, needed by /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so, not found (try using -rpath or -rpath-link)
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `rcu_bp_after_fork_child'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `cds_lfht_lookup'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `cds_lfht_next'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `cds_lfht_add_unique'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `rcu_flavor_bp'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `cds_lfht_destroy'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `_cds_lfht_new'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `rcu_bp_before_fork'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `rcu_read_lock_bp'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `cds_lfht_first'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `rcu_reader_bp'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `rcu_set_pointer_sym'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `cds_lfht_del'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `synchronize_rcu_bp'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `rcu_bp_after_fork_parent'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `rcu_bp_register'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `rcu_read_unlock_bp'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `rcu_gp_bp'
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `rcu_dereference_sym'
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)
src/pal/tests/palsuite/eventprovider/CMakeFiles/eventprovidertest.dir/build.make:100: recipe for target 'src/pal/tests/palsuite/eventprovider/eventprovidertest' failed
make[2]: *** [src/pal/tests/palsuite/eventprovider/eventprovidertest] Error 1
CMakeFiles/Makefile2:62048: recipe for target 'src/pal/tests/palsuite/eventprovider/CMakeFiles/eventprovidertest.dir/all' failed
make[1]: *** [src/pal/tests/palsuite/eventprovider/CMakeFiles/eventprovidertest.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Scanning dependencies of target gcinfo_crossgenn
[ 69%] Building CXX object src/gcinfo/crossgen/CMakeFiles/gcinfo_crossgen.dir/__/arraylist.cpp.o
...
[ 72%] Building CXX object src/jit/dll/CMakeFiles/clrjit_static.dir/__/__/__/version.cpp.o
[ 72%] Linking CXX static library libclrjit_static.a
[ 72%] Built target clrjit_static
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
Failed to build coreclr components.

ls -la /usr/lib/liburcu-cds.*
lrwxrwxrwx 1 root root    20 May  8 04:05 /usr/lib/liburcu-cds.so -> liburcu-cds.so.4.0.0
lrwxrwxrwx 1 root root    20 May  8 04:05 /usr/lib/liburcu-cds.so.4 -> liburcu-cds.so.4.0.0
-rwxr-xr-x 1 root root 30992 May  8 04:05 /usr/lib/liburcu-cds.so.4.0.0

@juergenhoetzel When you say "(clang3.5 + clang3.8)", are you merely saying you just have both installed? Or do you do any special configuration for the build? I only have 3.8 installed.

EDIT: Can't believe I had this comment on "Preview" all of these hours (smh)

[juergenhoetzel]

Where I'm confused is that when I look at the header between gcc5.3 and gcc6.1 I can see that min and max was already undefine in /PATH_TO_CPP_INCLUDES/bits/c++config.h. What am I missing here ?

@davzucky When compiling C++ code which is just using GLIBC headers the stdlib++ header (and thus also c++config.h)will be pulled in anyway because of this change in GCC6: wrappers for stdlib.h.

This wasn't the case with gcc < 6.0: There was no stdlib.hwrapper. So c++config.h wasn't pulled in.

As well how did you find this exclusion attribute. Any tips to find them ?

I just compared the C++ preprocessor output (clang -E) of GCC5 and GCC6 for mbstring.cpp

• GCC5:

extern void funlockfile (FILE *__stream) throw ();
#line 943 "/usr/include/stdio.h"
}
#line 572 "/home/juergen/cxx/coreclr/src/pal/src/include/pal/palinternal.h"
#line 1 "/usr/include/stdlib.h"
#line 32 "/usr/include/stdlib.h"
#line 1 "/usr/lib/llvm-3.5/bin/../lib/clang/3.5.0/include/stddef.h"
#line 33 "/usr/include/stdlib.h"

• GCC6:

extern void funlockfile (FILE *__stream) throw ();
#line 942 "/usr/include/stdio.h"
}
#line 572 "/home/juergen/cxx/coreclr/src/pal/src/include/pal/palinternal.h"
#line 1 "/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/stdlib.h"
#line 36 "/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/stdlib.h"
#line 1 "/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/cstdlib"
#line 40 "/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/cstdlib"

#line 1 "/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/x86_64-pc-linux-gnu/bits/c++config.h"
#line 196 "/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/x86_64-pc-linux-gnu/bits/c++config.h"

[juergenhoetzel]

/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib64/liblttng-ust.so: undefined reference to `rcu_dereference_sym'

@vindicatorr Seems your lttng-ust library (which is not part of the Arch Linux repos) needs a rebuild, because of a recent breaking liburcu update in the Arch Linux repos (including SONAME change).

@juergenhoetzel When you say "(clang3.5 + clang3.8)", are you merely saying you just have both installed? Or do you do any special configuration for the build? I only have 3.8 installed.

I did it on 2 different systems (one using clang3.5, the other using clang3.8)

[davzucky]

@juergenhoetzel , Thank you for the reply really useful. I will remember the usage of the precompiler option with clang. I was trying using strace, however I didn't get the same success as you.

[vindicatorr]

Whoo hoo, right you are @juergenhoetzel. It would have helped me if I actually looked past the warning to see the error (ugh). Built 100% and without clang 3.5 (using 3.8). (Ah, got it, you tested with each version).

[ghost]

@mmitche, @sergiy-k, since CoreCLR is building on Arch Linux and passing all tests at this point (https://github.com/dotnet/coreclr/issues/5304 patch applied), can we get the CI job configured for Arch as well so it doesn't regress?

[vindicatorr]

"Trojan:Win32/Maltule.C!cl" https://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?name=Trojan%3AWin32%2FMaltule.C!cl&threatid=2147709295&enterprise=0

Commit: 98568fb845ccaa97e18433ac13741913d6c8ffec

Just putting this out there as a heads-up. I'm guessing it's a false-positive from Windows-10 Windows Defender.

@jasonwilliams200OK I haven't forgotten about your requests (particularly in corefx). A few days ago, I corrupted my drive while copying tests from my VM guest to my host when I was hit with a very short power outage. I got back up and copied those test files again, but running them on my Arch host just didn't seem right, so I cleaned/reset/fetch/pull everything and started over. I'm currently in the middle of the build for the tests on my VM guest and suddenly got an alert from WinDef:

file:c:\Users\<username>\Desktop\coreclr\bin\tests\obj\Windows_NT.x64.Debug\Native\CMakeFiles\3.5.20160420-g860c1\CompilerIdC\CompilerIdC.exe

The thing is, I've been using that cmake release for awhile (assuming 4/20) and this is the first time I noticed it pop up as being a problem (surprised it didn't find the issue in the actual cmake bin location).

I submitted the file to VirusTotal which came out completely clean, including the Microsoft entry. Go figure. In any event, I just restored the file from quarantine and will soldier on.

[ghost]

Thanks @vindicatorr. Meanwhile, I built and ran PAL tests on Gentoo and result is 100% passing: https://gist.github.com/jasonwilliams200OK/f017dafead82920aaed9849977fe840f. IMO, Arch and Gentoo should be added to CI to preserve this status.

Next thing is to run general tests on Gentoo. If anyone is interested to run these tests, here is how I configured Gentoo container on Ubuntu and built CoreCLR https://gist.github.com/jasonwilliams200OK/1a2e2c0e904ffa95faf6333fcd88d9b8. To skip the part where we need Windows to build tests, grab the Debug config test zip from CI artifacts: http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_windows_nt/lastSuccessfulBuild/artifact/bin/tests/. I don't have enough bandwidth to continue with general test anytime soon. Annd, if you still have enough cycles to spare, try building CoreCLR on PuppyLinux! :dog: :smile:

[abrodersen]

I've put together an AUR package that I think works. Arch users, please help me test it: https://aur.archlinux.org/packages/dotnet-cli/

[vindicatorr]

Just took a quick look at the PKGBUILD and I'm wondering "mscorlib" getting built and all of the managed corefx files.

[abrodersen]

Right now, all the binaries are simply downloaded from Microsoft's Fedora tarball. It then builds all the native libraries locally and replaces them in the package. I don't know how else to get around the "bootstrap problem"

[vindicatorr]

Successfully installed and ran dotnet new, restore, run. Any other testing you're interested in?

[abrodersen]

Nope not really. I just wanted to be sure I had all the dependencies correct. Turns out I was missing lldb.

[vindicatorr]

Oh, I probably wasn't your target audience since I had been trying to build all of the core stuff by scratch so I already had all of the deps.

[aignas]

I just wanted to say, that I have uploaded an AUR PKGBUILD which can successfully build the master branch: https://aur.archlinux.org/packages/dotnet-coreclr-git/

I was not sure on what files need to be packaged, so at the moment it may be a bit random, but if someone could review it, I would gladly update the PKGBUILD to package the correct files.

This successfully built everything on my machine and it may be useful in setting up the CI job as @ghost suggested.

kudos to @abrodersen, whose dotnet-cli was a good starting point.

EDIT: just noticed that there was already a package for coreclr: https://aur.archlinux.org/packages/coreclr-git/

So it may be better to use this one.

[am11]

Seems like this issue was fixed. CoreCLR is building on Arch Linux (tested with current head 48431cc):

yes | pacman -Syu
yes | pacman -S tar awk make coreutils git cmake clang lldb llvm lttng-ust openssl-1.0

git clone https://github.com/dotnet/coreclr --single-branch --depth 1 --branch master
cd coreclr

./build.sh

...
...
Product binaries are available at /datadrive/projects/coreclr/bin/Product/Linux.x64.Debug

[janvorli]

I've been using arch linux on my RPI3 for some time and building on it occasionally too. I didn't remember we have this issue, thanks @am11 for pointing this out. Closing the issue.