|
Description
Dennis Schridde
2010-08-21 09:48:26 UTC
Created attachment 243827 [details]
ebuild for a CVS snapshot of pthreads-w32
I decided to build a CVS snapshot, because the last released version is 4 years old and had to be manually linked to wsock32.
Created attachment 243829 [details]
ebuild for last released version
This ebuild required some hack to L(D)FLAGS to make it build and also contains the correct MY_PV to match upstream release schemes.
Note regarding the CVS snapshot: 1) Download the source using the commands listed on upstream's website: cvs -d :pserver:anoncvs@sourceware.org:/cvs/pthreads-win32 login # pass=anoncvs cvs -d :pserver:anoncvs@sourceware.org:/cvs/pthreads-win32 checkout pthreads 2) Rename the folder to match the name expected by Gentoo: mv pthreads ${P} 3) Delete the CVS folders: find -name CVS | xargs rm -fr P.S: The ebuild contains some functions which were necessary to make it build here, and which I'd like to see in flag-o-matic: bug #333763 Created attachment 243831 [details]
ebuild for last released version
The ebuilds presented earlier were broken in that they did not install the header files.
Created attachment 243833 [details]
ebuild for a CVS snapshot
Created attachment 243835 [details]
ebuild for last released version
The assumption that libgomp would also search for pthreadGC2, because that's some kind of standard name, failed. -> This new ebuild has the library filename fixed.
Created attachment 243837 [details]
ebuild for a CVS snapshot
Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Thanks, On behalf of the Gentoo Sunrise Team, [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq Depends on bug #333763 for an addition/change to the flag-o-matic eclass. (test-flag-LD, test-flags-LD, strip-unsupported-flags) your ebuilds seem to have bad whitespace mangling. only indent with tabs. Created attachment 250089 [details]
eblit with flag-o-matic changes/extensions
Created attachment 250091 [details]
2.8.0 ebuild loading flag-o-matic changes as eblit
Created attachment 250093 [details]
2.9.0_pre ebuild loading flag-o-matic changes as eblit
(In reply to comment #11) > your ebuilds seem to have bad whitespace mangling. only indent with tabs. Was because of copy/paste from the terminal. Fixed in the new version, where I also put the flag-o-matic stuff into a new file. Created attachment 250095 [details]
2.8.0 ebuild loading flag-o-matic changes as eblit
Created attachment 250097 [details]
2.9.0_pre ebuild loading flag-o-matic changes as eblit
Missed on instance of the whitespace thing before. Repoman says I am clean now. Created attachment 283479 [details]
ebuild for 2.8.0
Attached ebuild is an improved version of the older ebuild.
It is prepared to be in sync with a live ebuild 2.8.9999 which I will attach in a minute.
Changes:
* support for building the C++ library
* support for building the debug variants
* theoretical support of the test phase (does not work out here, might be caused by wine)
- requires openmp for some tests, hence adds an additional but optional dependency
* theoretical support for compilers besides GCC (pthread-win32 atm does not support any when using GNU make, but I found it to be more self-documenting this way)
Fixes necessary for C++:
* fixes a compilation problem when using newer gcc (stdexcept had to be included)
* fixes a compilation problem with undefined ___gxx_personality_sj0, ___cxa_begin_catch and similar (libsupc++.a had to be linked)
Created attachment 283481 [details, diff]
patch to remove INLINE which caused undefined references
Created attachment 283483 [details, diff]
support CFLAGS and LDFLAGS on the make commandline
Created attachment 283485 [details, diff]
fix missing include
Created attachment 283487 [details, diff]
do not force -O3 on everyone
Created attachment 283489 [details, diff]
run tests with wine
Created attachment 283491 [details]
ebuild for 2.8.9999 (2.9.0_pre live from cvs)
Created attachment 283493 [details, diff]
support CFLAGS and LDFLAGS on the make commandline (for 2.8.9999)
Created attachment 283495 [details, diff]
do not force -O3 on everyone (for 2.8.9999)
Created attachment 283497 [details, diff]
run tests with wine (for 2.8.9999)
Created attachment 283499 [details]
eblit providing a function to find a file in a PATH like list of dirs
Necrobump! I actually need this now so I'm going to take a look. Dennis, if you're still around, I'm wondering why you made this a cross-* package. Would you not just do "x86_64-w64-mingw32-emerge pthreads-w32" instead? There has been talk about doing away with the cross/libc packages, if not more, and this feels like a step in the other direction. I am wondering we could ensure this gets installed. In theory, you'd have a virtual/pthreads package but so many packages need pthreads that this seems like more hassle than it's worth. crossdev could install it as an "extra" package and perhaps that's why you did the above but I've never bothered with the extras before and I imagine most other users would skip them. Hi James! (In reply to James Le Cuirot from comment #30) > Dennis, if you're still around, I'm wondering why you made this a cross-* > package. Would you not just do "x86_64-w64-mingw32-emerge pthreads-w32" > instead? There has been talk about doing away with the cross/libc packages, > if not more, and this feels like a step in the other direction. Well, this thing is 9 years old. A lot has changed since then... In fact I do not do much Windows development anymore, so I don't have hard feelings about you changing the category. > I am wondering we could ensure this gets installed. In theory, you'd have a > virtual/pthreads package but so many packages need pthreads that this seems > like more hassle than it's worth. crossdev could install it as an "extra" > package and perhaps that's why you did the above but I've never bothered > with the extras before and I imagine most other users would skip them. I think crossdev has changed a bit in the last decade. So probably there are better ways to do these things than what I wrote in 2010. |
