Issue compiling iconv during image creation (syntax error near unexpected token `reloc_final_prefix')

[Anacondo]

I am having trouble building a new image from scratch for Win64 GPL. There seems to be some kind of error running the configuration step for libiconv. I tried searching for the error but I cannot find anything anywhere. This is the log:

https://gist.github.com/Anacondo/efbdc835f806884472811aafae639149

I have been stuck at this step for close to a week now, but nothing seems to work. I can see that the automated builds are working here, but I'm not sure if they involve image creation or just building ffmpeg. Any idea how to proceed?

[BtbN]

Try deleting the download cache for iconv, maybe something went wrong during download. It builds just fine for me and on CI.

[Anacondo]

You mean the .cache folder in the filesystem, or something inside the docker image? For clarity, I always remove the .cache folder before starting a new image compilation, but it just keeps failing. I even cloned the repo again 20min ago in a new folder and tried to build the image and it also failed.

[BtbN]

Just the iconv cached download tarball in the download subdir there, yeah. If that doesn't help, I have no idea why it would fail on your system but not others.

[Anacondo]

I'll try a different system and report back. Which image did you compile? For me it's failing with "win64 gpl 7.1" if that's of any help, but it also fails with just "win64 gpl".

[BtbN]

The CI just rebuilt all images the other day. The iconv script is not different for any version. So it shouldn't matter which variant you build.

[Anacondo]

Same error on my 2nd machine: ./configure: line 13036: syntax error near unexpected token `reloc_final_prefix'

First one is running Debian and this one is running Arch. I have no idea how to proceed from here :(

[BtbN]

I still cannot reproduce this, so I'm not sure what to tell you. Did you apply any patches or did anything weird? The host distro or OS is entirely irrelevant.

[Anacondo]

I understand. I assume this is somehow an error on my end, but I'm working on a vanilla clone from master on 2 completely different systems, one AMD and one Intel, and I'm out of ideas. No patches or customization whatsoever. I am going to try booting a live installation CD and see if that changes anything.

[BtbN]

Do you have any ancient base images flying around? Make sure to delete any old tagged docker images, or run a complete docker system prune -a.

[Anacondo]

Yeah, I'm doing that before every compile: docker stop, docker system prune -af and rm -rf .cache to start from scratch. Unless there's any base images somewhere else I'm not aware of I assumed this would be the way to do a clean compile.

[BtbN]

I wouldn't delete the download cache, unless there is an issue with the downloaded artifacts. But yeah, I just did a full rebuild again, and everything works just fine. Not sure what to tell you.

[Anacondo]

I'm compiling from a live installation CD right now, I'll let you know how that goes. It's probably some weird thing that's specific to my system(s) only, otherwise more people would be complaining. I just don't know what else to try if this fails. Appreciate the support in any case! Cheers.

[BtbN]

That's very unlikely. Like I said, the host distro and OS is nearly irrelevant, since everything runs in docker containers.

[Anacondo]

Same error from the live environment unfortunately. Oh well...

The worst part is that this was working perfectly last week!

[nyanmisaka]

https://github.com/coreutils/gnulib/commit/d34065436725869d4d3fd7f46c8f51e65c33ae3c is the culprit, pin the submodule gnulib of libiconv to an older version.

[BtbN]

That does not explain why it works just fine for me locally and on CI. The submodule is already pinned, since it's a submodule.

[SLenik]

Hello!

I have the same issue too. And I think I've found the source of the problem.

That does not explain why it works just fine for me locally and on CI. The submodule is already pinned, since it's a submodule.

@BtbN, it is not a submodule, it is a subcheckout. You can see it in .gitmodules file.

As far as I unserstood this is not a canonical git feature. I've found an explanation in a gitsub.sh file:

  36 #   3) The package maintainer may choose to use or not use git submodules.
  37 #
  38 #      The advantages of management through a git submodule are:
  39 #        - Changes to the dependency package cannot suddenly break your package.
  40 #          In other words, when there is an incompatible change that will cause
  41 #          a breakage, you can fix things at your pace; you are not forced to
  42 #          cope with such breakages in an emergency.
  43 #        - When you need to make a change as a response to a change in the
  44 #          dependency package, your co-developers cannot accidentally mix things
  45 #          up (for example, use a combination of your newest change with an
  46 #          older version of the dependency package).
  47 #
  48 #      The advantages of management without a git submodule (just as a plain
  49 #      subdirectory, let's call it a "subcheckout") are:
  50 #        - The simplicity: you are conceptually always using the newest revision
  51 #          of the dependency package.
  52 #        - You don't have to remember to periodially upgrade the dependency.
  53 #          Upgrading the dependency is an implicit operation.

@BtbN I do not know why libiconv builds fine on your system. But I'm sure this is why it isn't building on my and @Anacondo computers.

[BtbN]

So they just always check out master of their submodules? That's ridiculously broken. In that case there is nothing I can do either, can only wait until that submodule gets updated again and the issue fixed.

[nyanmisaka]

So they just always check out master of their submodules? That's ridiculously broken. In that case there is nothing I can do either, can only wait until that submodule gets updated again and the issue fixed.

Yes. Manually checking out to the latest release can fix it.

./gitsub.sh pull
./gitsub.sh checkout gnulib d4ec02b3cc70cddaaa5183cc5a45814e0afb2292 # tag v1.0

[BtbN]

That's not an acceptable fix though, since it can't be automatically maintained. This needs to be fixed either upstream at gnulib or iconv.

[nyanmisaka]

Then we can only wait for the maintainer of libiconv to realize this issue.

[BtbN]

Is it really an issue in libiconv though? Or is the patch for gnulib broken? I can't immediately tell.

[nyanmisaka]

I know nothing about the GNU M4 macro processor (.m4 script). But from the error it looks like libiconv->libcharset doesn't work with that commit in gnulib.

[BtbN]

Should be worked around now, just not using that broken concept of subcheckouts anymore.