Shouldn't gcc-4 depend on libmpfr4 ?

[Csaba Raduly]

Hi all,
I installed cygwin on a new machine and running gcc failed with

/usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe: error while loading shared
libraries: cygmpfr-4.dll: cannot open shared object file: No such file
or directory

$ ldd /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe
ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x76ec0000)
kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75af0000)
KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll
(0x75650000)
cygcloog-0.dll => /usr/bin/cygcloog-0.dll (0x6fed0000)
cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x6f9c0000)
cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
cyggmp-3.dll => /usr/bin/cyggmp-3.dll (0x6f940000)
cygppl_c-2.dll => /usr/bin/cygppl_c-2.dll (0x6ecb0000)
cygppl-7.dll => /usr/bin/cygppl-7.dll (0x6ef20000)
cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x6e910000)
cyggmpxx-4.dll => /usr/bin/cyggmpxx-4.dll (0x6f930000)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x6f700000)
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x6f6a0000)
cygmpc-1.dll => /usr/bin/cygmpc-1.dll (0x6f410000)
cygmpfr-1.dll => /usr/bin/cygmpfr-1.dll (0x6f3c0000)
cygmpfr-4.dll => /usr/bin/cygmpfr-4.dll (0x68f40000)
cygz.dll => /usr/bin/cygz.dll (0x6e4c0000)
??? => ??? (0x1010000)

This appears to be due to the fact that gcc4-core depends on both
libmpfr1 and libmpfr4, but only libmpfr1 is listed as a dependency in
setup.ini:

@ gcc4-core
sdesc: "Core C compiler subpackage"
category: Devel
requires: alternatives binutils w32api libgcc1 libgomp1 libssp0
libffi4 libgmp3 libintl8 libmpfr1 libcloog0 libmpc1 libppl
_update-info-dir
version: 4.5.3-3


Installing libmpfr4 fixed the problem, but shouldn't this be automatic?

Csaba

[marco atzeri]

Post by Csaba Raduly
Hi all,
I installed cygwin on a new machine and running gcc failed with
/usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe: error while loading shared
libraries: cygmpfr-4.dll: cannot open shared object file: No such file
or directory

[cut]

Post by Csaba Raduly
This appears to be due to the fact that gcc4-core depends on both
libmpfr1 and libmpfr4, but only libmpfr1 is listed as a dependency in
@ gcc4-core
sdesc: "Core C compiler subpackage"
category: Devel
requires: alternatives binutils w32api libgcc1 libgomp1 libssp0
libffi4 libgmp3 libintl8 libmpfr1 libcloog0 libmpc1 libppl
_update-info-dir
version: 4.5.3-3
Installing libmpfr4 fixed the problem, but shouldn't this be automatic?

should be libmpfr4 instead of libmpfr1.

I guess it was an error introduced be the upload of the new test
gcc-4.7.2

Post by Csaba Raduly
Csaba

Marco

[Achim Gratz]

Post by marco atzeri
should be libmpfr4 instead of libmpfr1.

It looks like cc1 is linked against libmpfr1 _and_ libmpfr4, so they should both
be listed as dependencies.


Regards,
Achim.

[Corinna Vinschen]

Post by Achim Gratz

Post by marco atzeri
should be libmpfr4 instead of libmpfr1.

It looks like cc1 is linked against libmpfr1 _and_ libmpfr4, so they should both
be listed as dependencies.

No, the dependency is correct, but, oh well, that's something which
shouldn't happen. cc1 is linked against libmpc1, which in turn is
linked against libmpfr1, while cc1 is directly linked against libmpfr4.

David? Any chance to create a new mpclib package which fixes this
dependency problem?


Corinna

[Achim Gratz]

Post by Corinna Vinschen
No, the dependency is correct, but, oh well, that's something which
shouldn't happen. cc1 is linked against libmpc1, which in turn is
linked against libmpfr1, while cc1 is directly linked against libmpfr4.

Ah. Thanks for catching that.

Post by Corinna Vinschen
David? Any chance to create a new mpclib package which fixes this
dependency problem?

I have preliminary new-style cygport files for gmp, mpfr and mpc if it helps
anybody. Still fighting with some autotools issue (should be solved, fingers
crossed) on gmp and I need to look into a test build failure for mpfr.

It looks like libmfpr1 could be made obsolete after the new package has been
deployed.


Regards,
Achim.

[Tim Prince]

Post by Achim Gratz

Post by Corinna Vinschen
No, the dependency is correct, but, oh well, that's something which
shouldn't happen. cc1 is linked against libmpc1, which in turn is
linked against libmpfr1, while cc1 is directly linked against libmpfr4.

Ah. Thanks for catching that.

Post by Corinna Vinschen
David? Any chance to create a new mpclib package which fixes this
dependency problem?

I have preliminary new-style cygport files for gmp, mpfr and mpc if it helps
anybody. Still fighting with some autotools issue (should be solved, fingers
crossed) on gmp and I need to look into a test build failure for mpfr.
It looks like libmfpr1 could be made obsolete after the new package has been
deployed.

One of my posted applications

https://sites.google.com/site/tprincesite/levine-callahan-dongarra-vectors

is working for C and Fortran 77, but not for C++ nor Fortran 90, with
the 4.7.2 download.

I'll have another go when some of the issues already discussed are
reported fixed.

The installation is difficult when each component tries every time to
revert to the "stable" release, producing a broken installation of mixed
releases.

[Corinna Vinschen]

Post by Achim Gratz

Post by Corinna Vinschen
No, the dependency is correct, but, oh well, that's something which
shouldn't happen. cc1 is linked against libmpc1, which in turn is
linked against libmpfr1, while cc1 is directly linked against libmpfr4.

Ah. Thanks for catching that.

Post by Corinna Vinschen
David? Any chance to create a new mpclib package which fixes this
dependency problem?

I have preliminary new-style cygport files for gmp, mpfr and mpc if it helps
anybody. Still fighting with some autotools issue (should be solved, fingers
crossed) on gmp and I need to look into a test build failure for mpfr.
It looks like libmfpr1 could be made obsolete after the new package has been
deployed.

I just searched the archives, and it turned out that the problem is
known since at least September 2011. Unfortunately our maintainer of
the gmp, mpclib, and mpfr packages, David Billinghurst, never replied to
the problem report from Dave Korn.

I Bcced David, but if David has moved away from Cygwin, we will need a
new maintainer for the aforementioned packages, plus ppl and cloog-ppl.


Corinna

[Achim Gratz]

Post by Corinna Vinschen
I Bcced David, but if David has moved away from Cygwin, we will need a
new maintainer for the aforementioned packages, plus ppl and cloog-ppl.

If someone can sell me a clue on why autotools skips the renaming of lib*.dll to
cyg*.dll for gmp (this should normally be done via soname_spec, but it is always
empty in the generated libtool script), I could perhaps provide updated
packages, but at least working cygport files.


Regards,
Achim.

[Earnie Boyd]

Post by Achim Gratz

Post by Corinna Vinschen
I Bcced David, but if David has moved away from Cygwin, we will need a
new maintainer for the aforementioned packages, plus ppl and cloog-ppl.

If someone can sell me a clue on why autotools skips the renaming of lib*.dll to
cyg*.dll for gmp (this should normally be done via soname_spec, but it is always
empty in the generated libtool script), I could perhaps provide updated
packages, but at least working cygport files.

Perhaps it needs to be updated to use newer autotools, especially libtool.

[Achim Gratz]

Post by Earnie Boyd

Post by Achim Gratz
If someone can sell me a clue on why autotools skips the renaming of lib*.dll to
cyg*.dll for gmp (this should normally be done via soname_spec, but it is always
empty in the generated libtool script), I could perhaps provide updated
packages, but at least working cygport files.

Perhaps it needs to be updated to use newer autotools, especially libtool.

I've already done that, I've even ran autoupdate (and fixed some fallout
from that), but this didn't change things a bit. It might be that
LT_INIT is called at the wrong place, but I'm running out of ideas (for
today, anyway).


Regards,
Achim.

[Achim Gratz]

It might be that LT_INIT is called at the wrong place

It looks like moving LT_INIT later in the file whacked autotools into
submission. The remaining problem is that the library version changes from
cyggmp-3 to cyggmp-10. Not sure how to deal with that or if the new package
should just be libgmp10 instead of libgmp3 (I have the same problem with mpc,
the old way of forcing the version doesn't work there anymore).


Regards,
Achim.

[Corinna Vinschen]

Post by Achim Gratz

It might be that LT_INIT is called at the wrong place

It looks like moving LT_INIT later in the file whacked autotools into
submission. The remaining problem is that the library version changes from
cyggmp-3 to cyggmp-10. Not sure how to deal with that or if the new package
should just be libgmp10 instead of libgmp3 (I have the same problem with mpc,
the old way of forcing the version doesn't work there anymore).

I think we're better of to use the upstream numbering scheme, as
long as it doesn't collide with already used version numbers in the
Cygwin distro.


Corinna

[Yaakov (Cygwin/X)]

Post by Achim Gratz
The remaining problem is that the library version changes from
cyggmp-3 to cyggmp-10. Not sure how to deal with that or if the new
package should just be libgmp10 instead of libgmp3 (I have the same
problem with mpc, the old way of forcing the version doesn't work there
anymore).

As packagers, we shouldn't be messing around with DLL version numbers
unless a mistake has clearly been made and confirmed upstream. Correct
version bumps means ABI incompatibilities, so you can't just force back
the version without breaking existing software already built against
the old version.


Yaakov

[Yaakov (Cygwin/X)]

This post might be inappropriate. Click to display it.

[Achim Gratz]

Post by Yaakov (Cygwin/X)
The problem is a hack in gmp's configure.ac which is incompatible with
newer libtool versions.

Oh now you tell me... :-) I've found the same in the meantime after mucking with
the Win32_DLL red herring (that appears to be completely superfluous as well and
not have seen an update in ages - see the library version numbers). Anyway,
since the last version to have libmp (BSD compatibility) is 5.0.5 and I can't
easily tell if any other packages link against that, shouldn't Cygwin distribute
this version until the dependencies have been sorted?


Regards,
Achim.

[Yaakov (Cygwin/X)]

Post by Achim Gratz

Post by Yaakov (Cygwin/X)
The problem is a hack in gmp's configure.ac which is incompatible with
newer libtool versions.

Oh now you tell me... :-) I've found the same in the meantime after mucking with
the Win32_DLL red herring (that appears to be completely superfluous as well and
not have seen an update in ages - see the library version numbers). Anyway,
since the last version to have libmp (BSD compatibility) is 5.0.5 and I can't
easily tell if any other packages link against that, shouldn't Cygwin distribute
this version until the dependencies have been sorted?

AFAIK nothing used the BSD compat layer, it was disabled by default
upstream, and Fedora has already updated to 5.1. I think we can go
ahead and do the same.


Yaakov

[Achim Gratz]

Post by Yaakov (Cygwin/X)
AFAIK nothing used the BSD compat layer, it was disabled by default
upstream, and Fedora has already updated to 5.1. I think we can go
ahead and do the same.

I've produced a 5.0.5 package anyway so that library will be at the latest
existing version just to be sure. Now, the remaining problem is that updating
libmpc produces cygmpc-3.dll while gcc expects cygmpc-1.dll. Should these be
linked (the ABI is AFAICT the same since the original cygmpc-1.dll was produced
by overriding the version number)? After all, the trigger for the whole
exercise was to ensure that gcc doesn't pull in two different versions of
libmpfr via libmpc1...

Regards,
Achim.

[Yaakov (Cygwin/X)]

Post by Achim Gratz
I've produced a 5.0.5 package anyway so that library will be at the latest
existing version just to be sure. Now, the remaining problem is that
updating libmpc produces cygmpc-3.dll while gcc expects cygmpc-1.dll.
Should these be linked (the ABI is AFAICT the same since the original
cygmpc-1.dll was produced by overriding the version number)?

Absolutely NOT.

Post by Achim Gratz
After all, the trigger for the whole exercise was to ensure that gcc
doesn't pull in two different versions of libmpfr via libmpc1...

Forget the current gcc packages, they're history. We're about to
upgrade to 4.7 and we anyways need another rebuild before it goes
stable. If we ship all the updated prereqs now, each built against the
newest gmp, then 4.7.2-2 can be built against them and we won't have
this problem from here on out.


Yaakov

[Achim Gratz]

Post by Achim Gratz
I've produced a 5.0.5 package anyway so that library will be at the latest
existing version just to be sure. Now, the remaining problem is that updating
libmpc produces cygmpc-3.dll while gcc expects cygmpc-1.dll. Should these be
linked (the ABI is AFAICT the same since the original cygmpc-1.dll was produced
by overriding the version number)? After all, the trigger for the whole
exercise was to ensure that gcc doesn't pull in two different versions of
libmpfr via libmpc1...

Gcc now links to cyggmp-3.dll and cyggmp-10.dll and it doesn't like that a bit.
Here the ABI is different, so a symbolic link won't work.


Regards,
Achim.

[Yaakov (Cygwin/X)]

Post by Achim Gratz
Gcc now links to cyggmp-3.dll and cyggmp-10.dll and it doesn't like that a bit.

How so?

Post by Achim Gratz
Here the ABI is different, so a symbolic link won't work.

Of course not, that is the point of library versioning, after all.


Yaakov

[Achim Gratz]

Post by Yaakov (Cygwin/X)

Post by Achim Gratz
Gcc now links to cyggmp-3.dll and cyggmp-10.dll and it doesn't like that a bit.

How so?

I've built and installed a new gmp, then updated and built a new mpfr. It is
now linked to cyggmp-10.dll, but the mpfr library itself is still cygmpfr-4.dll
and gcc links itself to cyggmp-3.dll... classic dependency hell.

Post by Yaakov (Cygwin/X)
Of course not, that is the point of library versioning, after all.

Sure. In this case the library versioning doesn't do any good, however, since
it didn't change even though the result can't be linked.


Regards,
Achim.

[Yaakov (Cygwin/X)]

Post by Achim Gratz
I've built and installed a new gmp, then updated and built a new mpfr. It is
now linked to cyggmp-10.dll, but the mpfr library itself is still cygmpfr-4.dll
and gcc links itself to cyggmp-3.dll... classic dependency hell.

But does it affect the operation of gcc in any way?

Post by Achim Gratz
Sure. In this case the library versioning doesn't do any good, however, since
it didn't change even though the result can't be linked.

What do you mean "can't be linked"?


Yaakov

[Achim Gratz]

Post by Yaakov (Cygwin/X)
But does it affect the operation of gcc in any way?

Yes, gcc stops working: AFAICS it simply never starts and returns with 127.

Post by Yaakov (Cygwin/X)
What do you mean "can't be linked"?

When I try to do an ldd on gcc the output stops at the last library before
cyggmp-?.dll (I don't know if -3 or -10 would come first). So at the moment
I've just updated libmpc, which makes it libmpc3 (which no package links
against) and I could probably link cygmpc-1.dll to cygmpc-3.dll to remove the
double dependency of gcc to libmpfr1 and libmpfr4 as long as I keep libmpfr4
linked against the old libgmp3.

Again, the sticky thing here is libmpfr4, which doesn't change version, but
would link to different support library versions depending on whether gmp was
updated or not.


Regards,
Achim.

[Achim Gratz]

Hi Yaakov,

*** Info: No debug files, skipping debuginfo subpackage

Checking packages for missing or duplicate files

-usr/lib/debug/usr/bin/cygmpfr-4.dll.dbg

It seems cygport is not picking up the debuginfo files and leaves them
unpackaged. Why is this happening, is there anything I can do about this?

Also, you've changed the packaging in these cygport files (the shared components
were in the ${PN} package before), was this intentional?


Regards,
Achim.

[Yaakov (Cygwin/X)]

Post by Yaakov (Cygwin/X)

Post by Achim Gratz

Post by Earnie Boyd

Post by Achim Gratz
If someone can sell me a clue on why autotools skips the renaming of lib*.dll to
cyg*.dll for gmp (this should normally be done via soname_spec, but it is always
empty in the generated libtool script), I could perhaps provide updated
packages, but at least working cygport files.

Perhaps it needs to be updated to use newer autotools, especially libtool.

I've already done that, I've even ran autoupdate (and fixed some fallout
from that), but this didn't change things a bit. It might be that
LT_INIT is called at the wrong place, but I'm running out of ideas (for
today, anyway).

The problem is a hack in gmp's configure.ac which is incompatible with
newer libtool versions. As I've been working on 64bit packages, these
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gmp;a=tree
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/mpfr;;a=tree
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/libmpc;a=tree

And here are the rest:

http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ppl;a=tree
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/cloog-ppl;a=tree
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/isl;a=tree
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/cloog-isl;a=tree


Yaakov

[David Billinghurst]

Post by Corinna Vinschen
I just searched the archives, and it turned out that the problem is
known since at least September 2011. Unfortunately our maintainer of
the gmp, mpclib, and mpfr packages, David Billinghurst, never replied to
the problem report from Dave Korn.
I Bcced David, but if David has moved away from Cygwin, we will need a
new maintainer for the aforementioned packages, plus ppl and cloog-ppl.

Still lurking, but real life has led me in other directions for the last
year or so.

I am more than happy for someone else to adopt these packages. I have
had good intentions, and built a couple of test packages, but haven't
actually done anything useful for a while.

David

[Achim Gratz]

Post by David Billinghurst
Still lurking, but real life has led me in other directions for the last
year or so.
I am more than happy for someone else to adopt these packages. I have
had good intentions, and built a couple of test packages, but haven't
actually done anything useful for a while.

Hi David,

I have working packages that finally fit in with the current Cygwin
distribution. I can send the cygport files to you if you want to update them
yourself, otherwise I'll have to find time for a clean install to rebuild these
on before they are ready for update.


Regards,
Achim.

[Corinna Vinschen]

Hi guys,

Post by Achim Gratz

Post by David Billinghurst
Still lurking, but real life has led me in other directions for the last
year or so.
I am more than happy for someone else to adopt these packages. I have
had good intentions, and built a couple of test packages, but haven't
actually done anything useful for a while.

Hi David,
I have working packages that finally fit in with the current Cygwin
distribution. I can send the cygport files to you if you want to update them
yourself, otherwise I'll have to find time for a clean install to rebuild these
on before they are ready for update.

Shall I mark your packages as ORPHANED for now, David?


Corinna

[David Billinghurst]

Post by Corinna Vinschen
Hi guys,

Post by Achim Gratz

Post by David Billinghurst
Still lurking, but real life has led me in other directions for the last
year or so.
I am more than happy for someone else to adopt these packages. I have
had good intentions, and built a couple of test packages, but haven't
actually done anything useful for a while.

Hi David,
I have working packages that finally fit in with the current Cygwin
distribution. I can send the cygport files to you if you want to update them
yourself, otherwise I'll have to find time for a clean install to rebuild these
on before they are ready for update.

Shall I mark your packages as ORPHANED for now, David?
Corinna

Yes.

[Corinna Vinschen]

Post by Corinna Vinschen
Hi guys,

Post by Achim Gratz

Post by David Billinghurst
Still lurking, but real life has led me in other directions for the last
year or so.
I am more than happy for someone else to adopt these packages. I have
had good intentions, and built a couple of test packages, but haven't
actually done anything useful for a while.

Hi David,
I have working packages that finally fit in with the current Cygwin
distribution. I can send the cygport files to you if you want to update them
yourself, otherwise I'll have to find time for a clean install to rebuild these
on before they are ready for update.

Shall I mark your packages as ORPHANED for now, David?
Corinna

Yes.

Done.


Thanks,
Corinna