Thanks
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 17 2020
Aug 15 2020
Here's the patch:
Aug 14 2020
@JW: @gniibe explained you the problem and provided a fix (i.e. use correct specifiction of the directory names). Changes to Makefile.in are a no-go because that is a built file and a real fix would need to go into libtool. However, for a couple of reasons we do not want to update libtool (e.g. too many breakages in the past, we have out own fixes in for Windows). Thus we consider this bug closed.
I understand your point, but your fix is not relevant
Thanks for your patch. I understand your point, but your fix is not relevant (for supporting all platforms). You can use that way in your build script, but we can't take that approach; The correct fix is fixing libtool.
I'm feeling difficulty to talk to you.
@JW, I'm feeling difficulty to talk to you.
... no-support of slash at the end of path and duplicated slash, we won't fix.
T5024: libtool problem for some platforms for 'make check' (program built with -no-install won't work without installation)
For the original problem of no-support of slash at the end of path and duplicated slash, we won't fix.
@JW, I'm afraid you are not able to read what I write here. This is not chat system at all. For chat system, please use XMPP on
gnupg-devel@chat.gnupg.org as written at https://gnupg.org/documentation/mailing-lists.html (if possible).
I wrote that "FAIL: gpg-error-config-test.sh" is because of your typo
I wrote that "FAIL: gpg-error-config-test.sh" is because of your typo, and I asked to fix your typo and test again.
... you are now describing another problem
@JW, you are now describing another problem, instead of the problem you reported.
I'm closing this one.
Aug 10 2020
We currently already ship:
The problem appears to be the test framework is not setting a LD_LIBRARY_PATH (or DYNLD_LIBRARY_PATH on OS X).
As far as I know, the environment is set correctly. PKG_CONFIG_PATH, --prefix and --libdir are set. And runpaths are also set.
I meant:
If you can point me to a commit, I can patch the package and retest it.
If there is no other problem (than the issues of additional slash and double slash), I'll close this bug report.
Aug 5 2020
BTW, I learned that Fedora now uses pkgconfig (instead of pkg-config).
https://github.com/pkgconf/pkgconf
Try with --prefix=/home/jwalton/tmp/pk2delete (with no slash at the end) and --libdir=/home/jwalton/tmp/pk2delete/lib64 (with no double slash between pk2delete and lib64, but a single slash).
Aug 3 2020
Aug 2 2020
Jul 29 2020
We have had this in the past but it led to subtle build and, worse, runtime problems. Thus the decision to provide architecture dependent files and have configure complain for wrong files. Right, you sometimes get false warnings for non-matching cpu-vendor-os strings but I consider this less severe than the old problem.
I just saw that there is related discussion and a patch for this in T4994 so I will close again here.
This change broke for me the compilation of GPGME which I fixed with: 52f930c1ed7eee6336a41598c90ef3605b7ed02b I found that fix there OK because GPGME explicitly uses ws2_32.
Jul 9 2020
Jun 16 2020
You are very welcome, i'll let you know if i found more issues in the future, same goes to libgcrypt.
Jun 15 2020
It's me who should say "thank you".
Yes, i always build it with PKG_CONFIG_SYSROOT_DIR but never had any issues with it until 1.38 version, your suggestion definitely fixed it. Thank you.
Or one liner patch would be enough:
IIUC, you build libgpg-error with setting PKG_CONFIG_SYSROOT_DIR.
It results errors, because while old gpg-error-config never supports PKG_CONFIG_SYSROOT_DIR, it compares result from old gpg-error-config and gpgrt-config gpg-error.
Please give us full build log here, so that we can investigate what's going on. You can upload log file by the "upload" button in comment edit dialog.
Jun 13 2020
Confirm gpg-error-config works... no
- Please report to https://bugs.gnupg.org with gpg-error-config-test.log
Makefile:1667: recipe for target 'gpg-error-config' failed
Jun 12 2020
No problem, in fact there's several issues with the cross build code, i'll report them later today.
Sorry for repeated mistake of mine.
I fixed it and tested with 'make distcheck' in the environment of cross-build for ppc64el host.
Jun 11 2020
After this change:
Thanks for your report. I think it fails to generate src/lock-obj-pub.native.h.
Thank you also for the reply, the environment / build host is Ubuntu 18.04 LTS x86-x64 GNU/Linux and target host systems are MIPS and ARM.
Jun 10 2020
Thanks for the report. It would be helpful if you can tell us your environment; in particular your build and target(host ) system.
Jun 9 2020
Jun 3 2020
Let's wait with this until we ship a libgpgrt. I am not sure what the best way to migrate to another library name. By current idea is start with some release installing two libraries using the two names but with identical code. Some releases later we could require a configure option to install libgpg-error in addition to libgpgrt.
May 29 2020
FYIL This is delayed because there are some dependencies to internals of gnupg.
Merged. Thanks.
May 22 2020
May 21 2020
libgpg-error used to be blamed because of this kind of architectural support in earlier stage of building operating system.
T4774 is my try to fix the problem.
Thank you for your work. Please go ahead.
May 20 2020
If there's no objection to this in a few days, i'll go ahead and merge it to master.
May 19 2020
branch dkg/fix-4952 contains this fix in an easily applicable form as 0db8c768843db3e85935b972f1ed9d1b98159c46
May 14 2020
Apr 9 2020
Push the change to master.
Apr 6 2020
Clever idea.
I'm testing this as an initial start:
ac_ext=c ac_objext=o
Apr 2 2020
werner closed this task as Spite.
Apr 1 2020
See my comments on the other bugs you posted today.
Please see my other comments; we need proper bug reports and not just arbitrary snippets.
Mar 12 2020
Feb 27 2020
Feb 18 2020
Fixed in master, using Libs.private support.
Feb 10 2020
Note that we have a small pactch in the queue which should be applied by distributions to 1.37unless they want to wait for 1.38. See rEd72c1ddfde09ffa69745ec2439c5a16d15e2202f
Feb 7 2020
Feb 6 2020
Thanks. Fix goes into 1.37.
It has been fixed in the repo for nearly a year, see T4459. A new release is urgently required and will follow in the next days. I close this as a duplicate.
Jan 29 2020
Jan 2 2020
PS I forgot to say why movement to cmake will be the best way.
I totally disagree.
Please read libgpg-error's README. For each architecture we need to have a dedicated config file - this has nothing to do with autotools. Big and little endian variants are obviously different architectures. Here is an excerpt from the README
Jan 1 2020
Hello @wener, I want to say that libgpg-error is the only one (!) application that fails to cross compile using valid toolchains: "armeb-unknown-linux-gnueabi" and "aarch64_be-unknown-linux-gnu". It compiles and runs perfectly using "arm-unknown-linux-gnueabi" and "aarch64-unknown-linux-gnu", but fails with big endian. I see project are actually using "hton/ntoh" so we shouldn't see this error. What this problem is about?