Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 871324 - ERROR: app-text/xmlto-0.0.28-r9::gentoo_prefix failed (compile phase)
Summary: ERROR: app-text/xmlto-0.0.28-r9::gentoo_prefix failed (compile phase)
Status: CONFIRMED
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Prefix Support (show other bugs)
Hardware: ARM64 OS X
: Normal normal (vote)
Assignee: Gentoo Prefix
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-18 12:21 UTC by Askar Bektassov
Modified: 2023-02-03 08:06 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Askar Bektassov 2022-09-18 12:21:45 UTC
emerge fails during compilation, claiming that gm4 failed to execute

Reproducible: Always

Steps to Reproduce:
1.emerge xmlto
Actual Results:  
>>> Compiling source in /Users/askarbektassov/Gentoo/var/tmp/portage/app-text/xmlto-0.0.28-r9/work/xmlto-0.0.28 ...
make SHELL=/Users/askarbektassov/Gentoo/usr/bin/bash -j6
make  all-am
make[1]: Entering directory '/Users/askarbektassov/Gentoo/var/tmp/portage/app-text/xmlto-0.0.28-r9/work/xmlto-0.0.28'
/Users/askarbektassov/Gentoo/usr/bin/bash ./ylwrap xmlif/xmlif.l unknown.c xmlif/xmlif.c -- /Users/askarbektassov/Gentoo/usr/bin/bash '/Users/askarbektassov/Gentoo/var/tmp/portage/app-text/xmlto-0.0.28-r9/work/xmlto-0.0.28/missing' flex
flex: fatal internal error, exec of /Users/askarbektassov/Gentoo/usr/bin/gm4 failed
make[1]: *** [Makefile:777: xmlif/xmlif.c] Error 141
make[1]: Leaving directory '/Users/askarbektassov/Gentoo/var/tmp/portage/app-text/xmlto-0.0.28-r9/work/xmlto-0.0.28'

Expected Results:  
successful emerge

/Users/askarbektassov/Gentoo/usr/bin/gm4 is present and is works properly
Comment 1 Fabian Groffen gentoo-dev 2022-09-18 12:32:29 UTC
Can confirm, this seems new, and I have a suspicion it came through the latest updates.  What is your current OS/dev-tools?

12.6 + PROJECT:ld64-819.6

(sw_vers + ld -v)
Comment 2 Askar Bektassov 2022-09-18 18:11:25 UTC
(In reply to Fabian Groffen from comment #1)
> Can confirm, this seems new, and I have a suspicion it came through the
> latest updates.  What is your current OS/dev-tools?
> 
> 12.6 + PROJECT:ld64-819.6
> 
> (sw_vers + ld -v)

Right now, 12.6 + PROJECT:ld64-764, but bear in mind that I downgraded earlier today command line tools from Xcode 14 to Xcode 13.4 (see https://bugs.gentoo.org/show_bug.cgi?id=871336)

askarbektassov@Askars-MBP ~ $ sw_vers
ProductName:	macOS
ProductVersion:	12.6
BuildVersion:	21G115

askarbektassov@Askars-MBP ~ $ ld -v
ld: BINUTILS_CONFIG_LD not found in environment
ld: linker not found in PATH
ld: /Users/askarbektassov/Gentoo/etc/env.d/binutils/config-arm64-apple-darwin21 defines CURRENT=native-5
ld: trying from /Users/askarbektassov/Gentoo/etc/env.d/binutils/config-arm64-apple-darwin21: /Users/askarbektassov/Gentoo/usr/arm64-apple-darwin21/binutils-bin/native-5/ld
ld: invoking /Users/askarbektassov/Gentoo/usr/arm64-apple-darwin21/binutils-bin/native-5/ld with arguments:
  /Users/askarbektassov/Gentoo/usr/arm64-apple-darwin21/binutils-bin/native-5/ld
  -sdk_version
  12.0
  -syslibroot
  /Users/askarbektassov/Gentoo/MacOSX.sdk
  -search_paths_first
  -v
  -L/Users/askarbektassov/Gentoo/usr/lib
  -L/Users/askarbektassov/Gentoo/lib
  -rpath
  /Users/askarbektassov/Gentoo/usr/lib
  -rpath
  /Users/askarbektassov/Gentoo/lib
@(#)PROGRAM:ld  PROJECT:ld64-764
BUILD 11:22:55 Apr 28 2022
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
Library search paths:
	/Users/askarbektassov/Gentoo/usr/lib
	/Users/askarbektassov/Gentoo/lib
	/Users/askarbektassov/Gentoo/MacOSX.sdk/usr/lib
Framework search paths:
	/Users/askarbektassov/Gentoo/MacOSX.sdk/System/Library/Frameworks/
ld: warning: platform not specified
ld: warning: -arch not specified
ld: warning: No platform min-version specified on command line
ld: no object files specified
Comment 3 Askar Bektassov 2022-09-25 17:50:54 UTC
(In reply to Fabian Groffen from comment #1)
> Can confirm, this seems new, and I have a suspicion it came through the
> latest updates.  What is your current OS/dev-tools?
> 
> 12.6 + PROJECT:ld64-819.6
> 
> (sw_vers + ld -v)

FYI, still no progress. When I run the following code 

    ./ylwrap xmlif/xmlif.l unknown.c xmlif/xmlif.c -- /missing flex

In the working folder ($EPREFIX/var/tmp/portage/app-text/xmlto-0.0.28-r9/work/xmlto-0.0.28), all I get is a strange flex complain

    flex: fatal internal error, exec of $EPREFIX/usr/bin/gm4 failed

Using system gm4 does not help

    flex: fatal internal error, exec of /usr/bin/gm4 failed

At that point I thought to recompile flex with static libraries

    USE="static" emerge flex

But it was not happy, and emerge failed during configure phase.

checking for arm64-apple-darwin21-gcc... arm64-apple-darwin21-gcc
checking whether the C compiler works... no
configure: error: in `/Users/askarbektassov/Gentoo/var/tmp/portage/sys-devel/flex-2.6.4-r2/work/flex-2.6.4-.arm64':
configure: error: C compiler cannot create executables
See `config.log' for more details

!!! Please attach the following file when seeking support:
!!! /Users/askarbektassov/Gentoo/var/tmp/portage/sys-devel/flex-2.6.4-r2/work/flex-2.6.4-.arm64/config.log
 * ERROR: sys-devel/flex-2.6.4-r2::gentoo_prefix failed (configure phase):

Then I peeked into the config.log and it would seem that ld is unable to find lcrt0.o... should I create a separate bug?

configure:3031: checking whether the C compiler works
configure:3053: arm64-apple-darwin21-gcc  -O2 -pipe  -Wl,-dead_strip_dylibs -static conftest.c  >&5
ld: library not found for -lcrt0.o
collect2: error: ld returned 1 exit status
configure:3057: $? = 1
configure:3095: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "the fast lexical analyser generator"
| #define PACKAGE_TARNAME "flex"
| #define PACKAGE_VERSION "2.6.4"
| #define PACKAGE_STRING "the fast lexical analyser generator 2.6.4"
| #define PACKAGE_BUGREPORT "flex-help@lists.sourceforge.net"
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3100: error: in `/Users/askarbektassov/Gentoo/var/tmp/portage/sys-devel/flex-2.6.4-r2/work/flex-2.6.4-.arm64':
configure:3102: error: C compiler cannot create executables
See `config.log' for more details
Comment 4 Askar Bektassov 2022-09-25 17:56:23 UTC
(In reply to Askar Bektassov from comment #3)
> (In reply to Fabian Groffen from comment #1)
> > Can confirm, this seems new, and I have a suspicion it came through the
> > latest updates.  What is your current OS/dev-tools?
> > 
> > 12.6 + PROJECT:ld64-819.6
> > 
> > (sw_vers + ld -v)
> 
> FYI, still no progress. When I run the following code 
> 
>     ./ylwrap xmlif/xmlif.l unknown.c xmlif/xmlif.c -- /missing flex
> 
> In the working folder
> ($EPREFIX/var/tmp/portage/app-text/xmlto-0.0.28-r9/work/xmlto-0.0.28), all I
> get is a strange flex complain
> 
>     flex: fatal internal error, exec of $EPREFIX/usr/bin/gm4 failed
> 
> Using system gm4 does not help
> 
>     flex: fatal internal error, exec of /usr/bin/gm4 failed
> 
> At that point I thought to recompile flex with static libraries
> 
>     USE="static" emerge flex
> 
> But it was not happy, and emerge failed during configure phase.

Sorry, forget my last (unhelpful) comment. I understand that static linking is not possible in MacOS with llvm/clang gcc (https://stackoverflow.com/questions/3801011/ld-library-not-found-for-lcrt0-o-on-osx-10-6-with-gcc-clang-static-flag)
Comment 5 Askar Bektassov 2022-09-27 22:10:43 UTC
I managed installing two separate instances of CLT on my system. Do not know why, but for some reason if you do not use system '/bin/cp' and copy the parent directory '/Library/Developer', emerge will not be able to compile.

$ mkdir $EPREFIX/Library
$ /bin/cp -R /Library/Developer $EPREFIX/Library/
$ sudo xcode-select -s $EPREFIX/Library/Developer/CommandLineTools

Now you can update CLT 14, which will update the folder /Library/Developer, maintaining unchanged your own instance of CLT in $EPREFIX/Library/Developer/CommandLineTools
Comment 6 Askar Bektassov 2022-10-23 14:09:43 UTC
Hi, any news on this? My `emerge world -uDN` keeps failing :(
Comment 7 Fabian Groffen gentoo-dev 2022-10-23 15:56:50 UTC
sorry, no news :(  I think the toolchain needs to use a linker from our world, but still we need to figure out what special thing is going on here.
Comment 8 Askar Bektassov 2022-10-26 21:52:24 UTC
So far, the workaround for me was using LEX=/usr/bin/flex. Actually, even flex does not compile, unless I use macOS shipped flex.

LEX=/usr/bin/flex emerge flex
LEX=/usr/bin/flex emerge xmlto
Comment 9 Fabian Groffen gentoo-dev 2022-10-27 06:43:45 UTC
does it help if you set this in your etc/portage/make.conf?
Comment 10 Askar Bektassov 2022-10-27 06:56:13 UTC
Yep, I created a file etc/portage/make.conf/flex with LEX=/usr/bin/flex and both smalto and flex now compile smoothly.
Comment 11 Askar Bektassov 2022-11-01 21:21:15 UTC
(In reply to Askar Bektassov from comment #10)
> Yep, I created a file etc/portage/make.conf/flex with LEX=/usr/bin/flex and
> both smalto and flex now compile smoothly.

Should we consider this resolved? Besides, I have upgraded to CLT for Xcode 14.1, which in turn required me to umask gcc 12.2, and now everything seems to work fine. Last week I run `emerge system -e` and apparently everything went like a charm.
Comment 12 Fabian Groffen gentoo-dev 2022-11-02 07:09:02 UTC
Hmmm, ok, let me try that, would be great if it indeed works now, thanks!
Comment 13 Askar Bektassov 2022-12-11 21:37:32 UTC
I noticed that a new app-alternative/lex was introduced, which creates lex symlink to flex. Now the package compiles even without environment variable. Can we considered it solved?
Comment 14 Fabian Groffen gentoo-dev 2022-12-12 19:28:16 UTC
hmmm, what, if flex is called lex, it actually works, or does app-alternative/lex make symlink to host-system /usr/bin/lex?
Comment 15 Alexey 2023-02-02 19:43:10 UTC
Doesn't work for me on arm64-apple-darwin22

The lex symlink is pointing at local flex, not /usr/bin/lex

$ cd ~/Gentoo/usr/bin
$ ls -l lex
lrwxrwxrwx  1 sokolov  primarygroup  4 Feb  1 15:51 lex -> flex

Setting the environment variable in make.conf does help.
Comment 16 Alexey 2023-02-02 19:54:38 UTC
It uses flex instead of lex, so manually making the lex symlink to point at /usr/bin/lex doesn't help either.
Comment 17 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-02-02 19:58:04 UTC
(In reply to Alexey from comment #16)
> It uses flex instead of lex, so manually making the lex symlink to point at
> /usr/bin/lex doesn't help either.

Try exporting LEX=/usr/bin/lex, LEX=reflex, etc.
Comment 18 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-02-02 19:58:20 UTC
(In reply to Alexey from comment #15)
> Doesn't work for me on arm64-apple-darwin22
> 
> The lex symlink is pointing at local flex, not /usr/bin/lex
> 
> $ cd ~/Gentoo/usr/bin
> $ ls -l lex
> lrwxrwxrwx  1 sokolov  primarygroup  4 Feb  1 15:51 lex -> flex
> 
> Setting the environment variable in make.conf does help.

sorry, do you mean does, or does not help? Setting it to what?
Comment 19 Alexey 2023-02-02 21:00:43 UTC
Adding LEX=/usr/bin/flex to make.conf like suggested above, DOES help.

The default setup doesn't work (therefore I don't think this bug is fixed)

Then I replied to Fabian about new app-alternatives/lex that it wouldn't help either even if we make in the prefix some kind of "native" branch of that package which would make the symlink to /usr/bin/lex.
Comment 20 Fabian Groffen gentoo-dev 2023-02-03 08:06:44 UTC
At this point, a bashrc for a few packages that need this that exports LEX=/usr/bin/lex is the only thing we can do, until we figure out why it fails on the exec here on arm64.