From Gentoo Wiki
Jump to: navigation, search
This is a talk page. Please add newer comments below older ones, and sign your comments using four tildes (~~~~). When adding a new section (at the bottom of the page), please mark it as "open for discussion" by using {{talk|open}} so it will show up in the list of open discussions.

Confusing lines in article

Talk status
This discussion is done as of September 26, 2017.

What does this line even mean? It defiantly belongs in not the section it was in though.

less ${OVERLAY}/profiles/prefix/cygwin/make.defaults: Some values have automatically been added for: CPPFLAGS, LDFLAGS, USE, FEATURES. — The preceding unsigned comment was added by Wobbol (talkcontribs) December 3, 2014‎

This discussion seems to be outdated now. Haubi (talk) 07:48, 26 September 2017 (UTC)

cygwin using gcc 6.4.0 is causing problems with the default prefix build of gcc 5.3.0

Talk status
This discussion is done as of September 26, 2017.

A friendly warning may be in order for new/recent users - because cygwin-setup (v2.881) now installs gcc-6.4.0 (with the various associated updates in relation to ABI), the bootstrap script from Prefix breaks at stage2. The current Prefix GCC version is currently only gcc-5.3.0, which is incompatible. GCC stage2 build breaks with multiple instances of "warning: invalid suffix on literal; C++11 requires a space between literal and string macro". nautilus42jp 13:28, 25 September 2017 (UTC)

This sounds like, which I've fixed yesterday. Haubi (talk) 07:45, 26 September 2017 (UTC)

cygwin must not have too much dev stuff installed

Talk status
This discussion is done as of December 29, 2017.

Sorry for keeping this a bit vague. I have had great difficulties bootstrapping gentoo with cygwin-2.9.0 on windows 10. Well, the first try went well, but then I started from scratch, but wanted to use my own "latest-commit"-build of the cygwin1.dll with gentoo fork patches. So I cloned the newlib-cygwin repo in my home dir and built my own cygwin1.dll.

Unfortunately I couldn't boostrap any more thereafter. The installed dev tools in cygwin interfered so much, that the initial gcc-5.3.0 build just stopped after compilation ended. It simply showed, as a last line:

> leaving directory /build/portage/build/sys-devel/gcc-5.3.0/work

and then nothing. Forever. I cd'ed into the build directory and issued 'make' myself, and it was clear that gcc was completely built. Portage just froze.

I have no idea what exactly caused this. Maybe bison, cocom, flex, mingw-x86_64-gcc-g++ or mingw64-x86_64-zlib. But when I started again with a clean installation of cygwin, using the following line from CMD, everything worked just fine again.

Here is "the following line", I suggest adding this as a hint for newcomers to "Cygwin-on-steroids" (Aka Gentoo-prefixed ;-) )

> setup-x86_64.exe -P gcc-g++,nano,wget

(Some users may want to select 'vim' over 'nano', though) Yamakuzure (talk) 15:57, 27 December 2017 (UTC)

Well, I do build the cygwin1.dll within the same Cygwin instance than bootstrapping Gentoo Prefix, without any troubles so far.
Does it make a difference when you put your self-built cygwin1.dll into another fresh installed Cygwin instance without all the dev packages?
For the extra packages: There already is a section Additional packages. Are you talking about something else? Haubi (talk) 21:51, 27 December 2017 (UTC)

To clarify: I did build cygwin1.dll, which (naturally) needs mingw, before bootstrapping. I had to install a myriad of packages in cygwin to do so.

So this is really just a request for a note, that bootstrapping *might* fail if the process is not started with a fresh cygwin install. I am very sorry but I really have no idea which of the packages caused the trouble.

Well, I *do* suspect make, as that is what was running, and with cygwin-make installed, the script does not bootstrap a fresh one.

Btw.: To the list of recommended packages "unzip" should be added. Without unzip stage3 python 2.7 will fail with:

> >>> Unpacking to /build/portage/dev-lang/python-2.7.14/work
> /gentoo/usr/lib/portage/python2.7/ line 374: unzip: command not found

So the current bootstrap works (mostly) fine with my self built cygwin1.dll in a fresh instance of cygwin, and cygserver service running. Yamakuzure (talk) 13:07, 28 December 2017 (UTC)

Beyond adding app-arch/unzip as DEPENDency to the python ebuilds, in the python-2.7 ebuilds I've changed the order of LDFLAGS, which feels like might have been the reason for breaking upon host installed packages. In general, Prefix either should be able to use host tools for bootstrap, or ignore them and provide its own ones instead.
FWIW, to use current tree (updated daily at ~23:30 UTC) for bootstrap rather than a snapshot, one can use LATEST_TREE_YES=1 environment variable for Haubi (talk) 22:53, 29 December 2017 (UTC)

Perfect! I think this resolves everything! :-)

Oh, and a happy new year 2018 to you! Thank you very much for all your work and support, which is highly appreciated Yamakuzure (talk) 10:54, 8 January 2018 (UTC)

dynamic (shared) libraries and the -no-undefined option

Talk status
This discussion is still ongoing.

Every now and so often a package fails with libtool telling me that it can not create shared libraries unless the -no-undefined option is given.

If I then cd into the build directory, copy the command that failed and execute it by hand after adding -no-undefined, the build always succeeds.


 make[1]: Entering directory '/build/portage/dev-libs/libev-4.24/work/libev-4.24-.amd64'
 /gentoo/bin/bash ./libtool  --tag=CC   --mode=link x86_64-pc-cygwin-gcc  -march=native -O2 -pipe -version-info 4:0:0 -L/gentoo/usr/bin -L/gentoo/bin -L/gentoo/usr/lib -L/gentoo/lib -o -rpath /gentoo/usr/lib ev.lo event.lo
 libtool:   error: can't build x86_64-pc-cygwin shared library unless -no-undefined is specified
  $ cd /build/portage/dev-libs/libev-4.24/work/libev-4.24-.amd64
  $ /gentoo/bin/bash ./libtool  --tag=CC   --mode=link x86_64-pc-cygwin-gcc  -march=native -O2 -pipe -version-info 4:0:0 -L/gentoo/usr/bin -L/gentoo/bin -L/gentoo/usr/lib -L/gentoo/lib -o -rpath /gentoo/usr/lib ev.lo event.lo -no-undefined
 libtool: link: x86_64-pc-cygwin-gcc -shared  .libs/ev.o .libs/event.o   -L/gentoo/usr/lib -L/gentoo/lib  -march=native -O2   -o .libs/cygev-4.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libev.dll.a
 libtool: link: ( cd ".libs" && rm -f "" && ln -s "../" "" )
  $ ebuild /gentoo/usr/portage/dev-libs/libev/libev-4.24.ebuild compile
  * .amd64: running multilib-minimal_abi_src_compile
 make SHELL=/gentoo/bin/bash -j5 -l4
 make  all-am
 make[1]: Entering directory '/build/portage/dev-libs/libev-4.24/work/libev-4.24-.amd64'
 make[1]: Leaving directory '/build/portage/dev-libs/libev-4.24/work/libev-4.24-.amd64'
 >>> Source compiled.

Is there a possibility to add -no-undefined by default in a cygwin gentoo prefix? I tried adding -Wl,-no-undefined to LDFLAGS in my make.conf, but that causes lots failures otherwise. (Whenever ld is called directly.)

My LDFLAGS look like that at the moment:

 LDFLAGS="-L${EPREFIX}/usr/bin -L${EPREFIX}/bin -L${EPREFIX}/usr/lib -L${EPREFIX}/lib"

And here is why I am putting this on the talk page of a wiki article, and not posting in some forums:

  1. If there is a possibility to add said -no-undefined globally, I think it could help other users as well if it got mentioned in the article.
  2. Many shared libraries are installed as ${EPREFIX}/bin/cyg<libname>.dll (100 on my system currently), it therefore sounds like a good idea to mention that adding -L${EPREFIX}/bin to the LDFLAGS in make.conf helps (some) packages to find the right libraries to link against when building.

What do you think?

Yamakuzure (talk) 09:21, 12 January 2018 (UTC)

Forkables not yet in newlib 3.0

Talk status
This discussion is still ongoing.

In the "Additional Setup" section, first bullet, the user is advised to "Use Cygwin 3.0 (or higher - not available yet)".

Do you really mean "Cygwin" and not "newlib"?

However, newlib-3.0.0 got tagged on january 18th, and the topic/forkables patches aren't included. :-(

Note: I am currently testing the topic/forkables and your gentoo branch additions rebased on upstream/master on - rebasing on master did not produce any conflicts...

Yamakuzure (talk) 09:13, 8 February 2018 (UTC)