Bug 819670 (mingw-llvm)

Updated to fix optimization flags.  Not sure why the debuginfo isn't picking up the sources; could use some help with that.

Spec URL: http://fedorapeople.org/~brouhaha/mingw-llvm/mingw-llvm.spec
SRPM URL:
http://fedorapeople.org/~brouhaha/mingw-llvm/mingw-llvm-3.0-2.fc17.src.rpm

Here's the Koji scratch build for F17 for 3.0-2:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4061825

Kalev Lember let me know that for MinGW packages it is expected that the debuginfo not include sources, so the error from rpmlint is not an issue:
    http://lists.fedoraproject.org/pipermail/mingw/2012-May/005299.html

I've added a note about this to the MinGW/Rpmlint wiki page:
    http://fedoraproject.org/w/index.php?title=MinGW/Rpmlint

Updated to fix a problem in the llvm-config script, which was attempting to be clever in determining the include and library paths, depending on whether the script was being run from the build directory.  In this package it was computing the wrong path, so it has been patched to always simply use the configured PREFIX.

Spec URL: http://fedorapeople.org/~brouhaha/mingw-llvm/mingw-llvm.spec
SRPM URL:
http://fedorapeople.org/~brouhaha/mingw-llvm/mingw-llvm-3.0-3.fc17.src.rpm
Koji scratch build for f17:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4069804

Note that the mingw-llvm-static subpackage is not useful without a static subpackage of libffi.  I have modified the spec for mingw-libffi to create the static subpackage and verify that it works.  I have sent a patch to Erik van Pienbroek requesting that he add it.

mingw-libffi-3.0.11-0.3.rc2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mingw-libffi-3.0.11-0.3.rc2.fc17

Perhaps I'm misunderstanding things, but what is the use case for this package? Is llvm.exe and the other tools intended to be called using wine? How does one get something linked against the LLVM-3.0.dll or is this only intended as direct dependency of the llvm.exe and the other tools? What purpose do the static libraries have?

As epienbro says, what's the point?  There should perhaps be an llvm
cross-compiler, ie. a native llvm binary that can generate Windows
executables, but I don't see much point in an llvm.exe.

The purpose of mingw-llvm is to be able to build applications for Windows that use the LLVM libraries, e.g., if they want to use the LLVM JIT capabilities.  Such an app might possibly also be able to emit bitcode or even native code files, though that isn't what I use it for personally.

The purpose of static libraries is to allow such programs to be built statically, to avoid having to distribute them with a bunch of DLLs (including but not limited to the LLVM DLLs).  In other words, exactly the same reason as for packaging any other mingnn-*-static subpackage.

I don't have any clue what an "llvm.exe" would do, even if it existed, which AFAIK it doesn't.  Certainly this package doesn't contain one.

The various .exe files that are in this package may or may not be useful to people that use applications built with mingw-llvm, depending on exactly what those applications do.  I've had occasion to use a few of them.  I could remove them from the package, and only include the libraries, but I thought that as long as the exe files were built and work, there was little advantage to not packaging them.

Re:
   How does one get something linked against the LLVM-3.0.dll

Pretty much the same way one builds a Windows application linked against any other MinGW DLL.  In this case, using /usr/bin/i686-w64-mingw32-llvm-config in the same way that pkg-config might be used for building against MinGW libraries that include a .pc file.

mingw-libffi-3.0.11-0.3.rc2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Taking for review.

$ md5sum Downloads/llvm-3.0.tar.gz 
a8e5f5f1c1adebae7b4a654c376a6005  Downloads/llvm-3.0.tar.gz
$ md5sum rpmbuild/SOURCES/llvm-3.0.tar.gz 
a8e5f5f1c1adebae7b4a654c376a6005  rpmbuild/SOURCES/llvm-3.0.tar.gz

$ rpmlint rpmbuild/SPECS/mingw-llvm.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
$ rpmlint Downloads/mingw-llvm-3.0-3.fc17.src.rpm 
mingw-llvm.src: W: spelling-error %description -l en_US runtime -> run time, run-time, rudiment
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
$ rpmlint /home/michael/rpmbuild/RPMS/noarch/mingw32-llvm-3.0-3.fc17.noarch.rpm
mingw32-llvm.noarch: W: no-manual-page-for-binary i686-w64-mingw32-llvm-config
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
$ rpmlint /home/michael/rpmbuild/RPMS/noarch/mingw32-llvm-static-3.0-3.fc17.noarch.rpm
mingw32-llvm-static.noarch: W: no-documentation
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

$ rpm -qp --requires /home/michael/rpmbuild/RPMS/noarch/mingw32-llvm-3.0-3.fc17.noarch.rpm
/usr/bin/perl  
mingw32(advapi32.dll)  
mingw32(imagehlp.dll)  
mingw32(kernel32.dll)  
mingw32(libgcc_s_sjlj-1.dll)  
mingw32(libstdc++-6.dll)  
mingw32(llvm-3.0.dll)  
mingw32(msvcrt.dll)  
mingw32(psapi.dll)  
mingw32(shell32.dll)  
mingw32-crt  
mingw32-filesystem >= 83
perl >= 0:5.006
perl(Cwd)  
perl(strict)  
perl(warnings)  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

$ rpm -qp --provides /home/michael/rpmbuild/RPMS/noarch/mingw32-llvm-3.0-3.fc17.noarch.rpm
mingw32(bugpointpasses.dll)  
mingw32(llvm-3.0.dll)  
mingw32(lto.dll)  
mingw32-llvm = 3.0-3.fc17

+ OK
! Needs to be looked into
/ Not applicable

[+] Compliant with generic Fedora Packaging Guidelines
[+] Source package name is prefixed with 'mingw-'
[+] Spec file starts with %{?mingw_package_header}
[+] BuildRequires: mingw32-filesystem >= 95 is in the .spec file
[/] BuildRequires: mingw64-filesystem >= 95 is in the .spec file
[+] Spec file contains %package sections for both mingw32 and mingw64 packages
[+] Binary mingw32 and mingw64 packages are noarch
[+] Spec file contains %{?mingw_debug_package} after the %description section
[+] Uses one of the macros %mingw_configure, %mingw_cmake, or %mingw_cmake_kde4
    to configure the package
[+] Uses the macro %mingw_make to build the package
[+] Uses the macro %mingw_make to install the package
[/] If package contains translations, the %mingw_find_lang macro must be used
[+] No binary package named mingw-$pkgname is generated
[/] Libtool .la files are not bundled
[/] .def files are not bundled
[+] Man pages which duplicate native package are not bundled
[/] Info files which duplicate native package are not bundled
[+] Provides of the binary mingw32 and mingw64 packages are equal
[+] Requires of the binary mingw32 and mingw64 packages are equal

The description and man page rpmlint warnings can be ignored.

The no-documentation rpmlint warnings in the -static subpackage can be ignored
as the documentation is already part of the regular mingw32 package.

However, I could not build your package on my x86_64 F17 system at first. The configure steps succeed but building fails during the make step:

checking tool compatibility... configure: error: g++|clang++|icc required but not found
make[1]: Entering directory `/home/michael/rpmbuild/BUILD/llvm-3.0.src/build_win32/BuildTools'
make[1]: *** No targets specified and no makefile found.  Stop.
make[1]: Leaving directory `/home/michael/rpmbuild/BUILD/llvm-3.0.src/build_win32/BuildTools'
make: *** [cross-compile-build-tools] Error 1

It seems when it runs make it is throwing out all of the MinGW environment variables and running configure again. I do not have g++ installed on the system I am reviewing on. After installing it (as a koji buildroot would have it) building succeeded. You might ask upstream why the "make" process wants native compilers when we specified a cross-compiler (MinGW) during configure. In any case it seems to build Windows binaries.

================================================
 The package mingw-llvm is APPROVED by mooninite
================================================

New Package SCM Request
=======================
Package Name: mingw-llvm
Short Description: MinGW LLVM libraries for cross-development use
Owners: brouhaha
Branches: f17 el6
InitialCC:

Thanks Michael!  I'll look into why it wanted the native C++ compiler.  I'm also working on updating this to llvm 3.1, which does have to build a native executable for llvm-config, which was formerly a script, so 3.1 will definitely need a native compiler.

Are you sure about the el6 branch? The new MinGW packaging guidelines (and thus your current .spec file) currently only work on Fedora 17 and higher. If you really want to target el6 then you have to use the old MinGW packaging guidelines which can be found at https://fedoraproject.org/wiki/Packaging:MinGW_Old

New Package SCM Request
=======================
Package Name: mingw-llvm
Short Description: MinGW LLVM libraries for cross-development use
Owners: brouhaha
Branches: f17
InitialCC:

Git done (by process-git-requests).

Package was imported and built successfully in f18 (before the f19 branch) : https://koji.fedoraproject.org/koji/packageinfo?packageID=14273

Closing ticket