GNU bug report logs - #68179
automake-1.16j on OpenBSD

Previous Next

To reply to this bug, email your comments to 68179 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-automake <at> gnu.org
Subject: Re: automake-1.16j on OpenBSD
Date: Sun, 31 Dec 2023 17:01:26 +0100

[Message part 1 (text/plain, inline)]

On OpenBSD 7.4/x86_64, with
  CC="cc -ferror-limit=0"
  CXX="c++ -ferror-limit=0"
I see 4 test failures in "make check":

$ grep ^FAIL: test-suite.log 
FAIL: t/objcxx-minidemo
FAIL: t/objcxx-deps
FAIL: t/strip2
FAIL: t/yacc-mix-c-cxx

[test-suite.log.xz (application/x-xz, attachment)]

Message #8 received at 68179 <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: 68179 <at> debbugs.gnu.org, bruno <at> clisp.org
Subject: [bug#68179] Re: automake-1.16j on OpenBSD
Date: Tue, 13 Feb 2024 23:27:13 +0100

[Message part 1 (text/plain, inline)]

Hello, Bruno.

Thank you for your testing.
About your defect:
1) t/objcxx-* - may need our attention,
2) t/strip2 - could you check if you have the STRIPPROG environment
variable set and, if yes, unset it (or, at least, remove the
"--verbose" parameter from it) prior to running the test?
3) t/yacc-mix-c-cxx - can you apply the attached patch and re-run the
test?

--
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

[automake-sunos-openbsd-fix.diff (text/x-patch, attachment)]

Message #11 received at 68179 <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: 68179 <at> debbugs.gnu.org, bruno <at> clisp.org
Subject: Re: [bug#68179] Re: automake-1.16j on OpenBSD
Date: Sun, 18 Feb 2024 23:00:01 +0100

> Hello, Bruno.
>
> Thank you for your testing.
> About your defect:
> 1) t/objcxx-* - may need our attention,
> 2) t/strip2 - could you check if you have the STRIPPROG environment
> variable set and, if yes, unset it (or, at least, remove the
> "--verbose" parameter from it) prior to running the test?
> 3) t/yacc-mix-c-cxx - can you apply the attached patch and re-run the
> test?


 Can you tell us what actually "c++" is on your system? Like e.g. run
"c++ --version" or "c++ --help"?
 On my system, Autoconf finds "g++", tests it for an Objective C++
compiler, fails, and the t/objcxx-* tests are simply skipped.
 It seems that on your system, "c++" actually works as an Objective
C++ compiler, but somehow the "libobjc" library is not added to the
command line, making the test fail during linking.
 What Autoconf version do your have and can you upgrade that? I
suspect it's not passing the required libraries. If it's the newest
version, can you attach the config.log file?

--
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

Message #14 received at 68179 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: 68179 <at> debbugs.gnu.org, Bogdan <bogdro_rep <at> gmx.us>
Subject: Re: [bug#68179] Re: automake-1.16j on OpenBSD
Date: Mon, 19 Feb 2024 01:33:14 +0100

Hello Bogdan,

Thank you for dealing with the Automake support.

> 2) t/strip2 - could you check if you have the STRIPPROG environment
> variable set and, if yes, unset it (or, at least, remove the
> "--verbose" parameter from it) prior to running the test?

I did not have the STRIPPROG environment variable set.

> 3) t/yacc-mix-c-cxx - can you apply the attached patch and re-run the
> test?

With the patch, the test succeeds.

Note, however, that 'defined __sun' is not an appropriate test for
Sun C++ (since g++ also exists on Solaris). For compiler predefined
macros, see here:
https://github.com/cpredef/predef/blob/master/Compilers.md

Bruno

Message #17 received at 68179 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: 68179 <at> debbugs.gnu.org, Bogdan <bogdro_rep <at> gmx.us>
Subject: Re: [bug#68179] Re: automake-1.16j on OpenBSD
Date: Mon, 19 Feb 2024 01:44:29 +0100

[Message part 1 (text/plain, inline)]

Hello Bogdan,

>   Can you tell us what actually "c++" is on your system? Like e.g. run
> "c++ --version" or "c++ --help"?

$ c++ --version
OpenBSD clang version 13.0.0
Target: amd64-unknown-openbsd7.4
Thread model: posix
InstalledDir: /usr/bin

>   On my system, Autoconf finds "g++", tests it for an Objective C++
> compiler, fails, and the t/objcxx-* tests are simply skipped.
>   It seems that on your system, "c++" actually works as an Objective
> C++ compiler, but somehow the "libobjc" library is not added to the
> command line, making the test fail during linking.

Yes, 'c++' works as an Objective-C++ compiler:
================================= hello.mm ==========================
#import <stdio.h>
#import <stdlib.h>
#import <iostream>

class X { int a; };

int main(void)
{
    @autoreleasepool
    {
        std::cout << @"Hello, Objective-C++.";
    }
    
    return EXIT_SUCCESS;
}
======================================================================
$ c++ -c hello.mm
$ c++ hello.mm
[3 link errors, due to undefined symbols.]

>   What Autoconf version do your have and can you upgrade that?

I was testing automake-1.16j.

> I suspect it's not passing the required libraries. If it's the newest
> version, can you attach the config.log file?

Find attached the config.log.

Bruno

[config.log (text/x-log, attachment)]

Message #20 received at 68179 <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: Bruno Haible <bruno <at> clisp.org>, 68179 <at> debbugs.gnu.org
Subject: Re: [bug#68179] Re: automake-1.16j on OpenBSD
Date: Mon, 19 Feb 2024 22:18:22 +0100

Bruno Haible <bruno <at> clisp.org>, 2024-02-19 01:33:
> Hello Bogdan,
>
> Thank you for dealing with the Automake support.


 Thank you for testing :)


>> 2) t/strip2 - could you check if you have the STRIPPROG environment
>> variable set and, if yes, unset it (or, at least, remove the
>> "--verbose" parameter from it) prior to running the test?
>
> I did not have the STRIPPROG environment variable set.


 Right. Going through the logs, through various variables, up a few
levels, this finally leads to the line

	./configure --prefix="$(pwd)/inst" STRIP='strip --verbose'

 in the test itself, and the test's description:

# Ensure install-strip works when STRIP consists of more than one word.
# This test needs GNU binutils strip.  See sister test 'strip3.sh'.


 And, frankly, I don't know what to do about this. It's the whole
point of the test to use 'strip --verbose' (well, 'strip' + any word,
actually). Fortunately, doesn't look like a bug in Automake itself.

 Perhaps we can test with some other option. Is there some useful
command-line option that your 'strip' accepts, while still performing
its work? Like neither --help nor --version?
 Come to think of it, we're not testing if the files actually got
installed, so maybe --help or --version would do after all. If you
change the above line to

	./configure --prefix="$(pwd)/inst" STRIP='strip --help'

 does the test pass? (You can choose --version as well, I guess.). If
not, any other option you may suggest? We could then re-write the test
a bit to say if 'strip --verbose' works, use that. If not, try --help.


>> 3) t/yacc-mix-c-cxx - can you apply the attached patch and re-run the
>> test?
>
> With the patch, the test succeeds.


 Good to hear.


> Note, however, that 'defined __sun' is not an appropriate test for
> Sun C++ (since g++ also exists on Solaris). For compiler predefined
> macros, see here:
> https://github.com/cpredef/predef/blob/master/Compilers.md


 The question is if we want to detect the compiler or the operating
system. I'm toying around with a SunOS with GCC installed, I'm using
__sun and some of the tests that previously failed, now work. At least
with GCC. But thanks for the reference anyway - if we need something
specific to the Sun compiler, we'll know where to look.


--
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

Message #23 received at 68179 <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: Bruno Haible <bruno <at> clisp.org>, 68179 <at> debbugs.gnu.org
Subject: Re: [bug#68179] Re: automake-1.16j on OpenBSD
Date: Mon, 19 Feb 2024 22:36:01 +0100

Bruno Haible <bruno <at> clisp.org>, 2024-02-19 01:44:
> Hello Bogdan,
>
>>    Can you tell us what actually "c++" is on your system? Like e.g. run
>> "c++ --version" or "c++ --help"?
>
> $ c++ --version
> OpenBSD clang version 13.0.0
> Target: amd64-unknown-openbsd7.4
> Thread model: posix
> InstalledDir: /usr/bin
>
>>    On my system, Autoconf finds "g++", tests it for an Objective C++
>> compiler, fails, and the t/objcxx-* tests are simply skipped.
>>    It seems that on your system, "c++" actually works as an Objective
>> C++ compiler, but somehow the "libobjc" library is not added to the
>> command line, making the test fail during linking.
>
> Yes, 'c++' works as an Objective-C++ compiler:


 How interesting. Especially that it compiles, but doesn't link.

[...]

> $ c++ -c hello.mm
> $ c++ hello.mm
> [3 link errors, due to undefined symbols.]
>
>>    What Autoconf version do your have and can you upgrade that?
>
> I was testing automake-1.16j.


 Good (even though it's 1.16.90 now :) ). Even though this looks like
a typo, I really was asking for Autoconf, suspecting a faulty test
there. But no problem, I see in config.log that it's the
latest-and-greatest 2.72.


>> I suspect it's not passing the required libraries. If it's the newest
>> version, can you attach the config.log file?
>
> Find attached the config.log.


 Right. And, as I suspected, nothing in any LIBS, LD*, no libobjc found.
 Does it work if you put

AC_LANG([Objective C])

 somewhere between the lines

	cat >> configure.ac << 'END'

and the first

	END

following it (i.e., in the 'configure.ac' file) in the test?

 If not, do you know any function name that we could use in
AC_CHECK_LIB to check for libobjc?
 Fortunately, this looks like just an issue with tests (or Autoconf),
not Automake.

--
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

Message #26 received at 68179 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: 68179 <at> debbugs.gnu.org, Bogdan <bogdro_rep <at> gmx.us>
Subject: Re: [bug#68179] Re: automake-1.16j on OpenBSD
Date: Tue, 20 Feb 2024 12:44:44 +0100

Bogdan wrote:
>   Right. And, as I suspected, nothing in any LIBS, LD*, no libobjc found.
>   Does it work if you put
> 
> AC_LANG([Objective C])
> 
>   somewhere between the lines
> 
> 	cat >> configure.ac << 'END'
> 
> and the first
> 
> 	END
> 
> following it (i.e., in the 'configure.ac' file) in the test?

No: With this added configure.ac line (before AC_OUTPUT), the
two tests t/objcxx-minidemo.sh and t/objcxx-deps.sh still fail.

>   If not, do you know any function name that we could use in
> AC_CHECK_LIB to check for libobjc?

My test program
================================= hello.mm ==========================
#import <stdio.h>
#import <stdlib.h>
#import <iostream>

class X { int a; };

int main(void)
{
    @autoreleasepool
    {
        std::cout << @"Hello, Objective-C++.";
    }
    
    return EXIT_SUCCESS;
}
======================================================================
produces link errors w.r.t. the symbols
  objc_autoreleasePoolPush
  objc_autoreleasePoolPop
  __objc_exec_class
Is one of them suitable for testing? It depends on the ABI. Looking at
https://opensource.apple.com/source/objc4/objc4-706/runtime/objc-abi.h.auto.html
it seems better to choose one of the symbols
  _objcInit
  objc_getProperty
  objc_setProperty
  objc_setProperty_atomic
  objc_setProperty_nonatomic
  ...
  objc_copyStruct
  objc_copyCppObjectAtomic
  _objc_empty_cache
  ...

But wait! The name of the library 'libobjc' is not standardized either.

I would try to just compile a simple Objective-C++ program and see whether that
works or not. Such as:
================================ foo.mm ==============================
@interface MyClass { int _field; }
@property(nonatomic, assign) int myProperty;
@end

@implementation MyClass
@synthesize myProperty = _field;
@end

MyClass *myObject;

int main () {
  myObject.myProperty = 10;
  return 0;
}
=======================================================================
Missing symbols with clang on OpenBSD:
  objc_msg_lookup_sender
  __objc_exec_class
Missing symbols with clang on Ubuntu:
  objc_msg_lookup
  __objc_exec_class

Bruno

Message #29 received at 68179 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: 68179 <at> debbugs.gnu.org, Bogdan <bogdro_rep <at> gmx.us>
Subject: Re: [bug#68179] Re: automake-1.16j on OpenBSD
Date: Tue, 20 Feb 2024 13:51:30 +0100

Bogdan wrote:
> # Ensure install-strip works when STRIP consists of more than one word.
> # This test needs GNU binutils strip.  See sister test 'strip3.sh'.
> 
> 
>   And, frankly, I don't know what to do about this. It's the whole
> point of the test to use 'strip --verbose' (well, 'strip' + any word,
> actually).

Here's the point. On a system with GNU binutils, "man strip" shows
the options
  [-s|--strip-all]
  [-S|-g|-d|--strip-debug]
  [-v|--verbose]
  [-x|--discard-all]
(among others).

Whereas on OpenBSD, "man strip" shows that it's in fact 'llvm-strip'
and that it supports the options
  [-s|--strip-all]
  [-S|-g|-d|--strip-debug]
  [-x|--discard-all]
(among others), but not [-v|--verbose].

Then there's also AIX 'strip', which understands
  -l
  -x
and Solaris 'strip', which understands
  -l
  -x
as well.

So, in summary, I suggest to use the option '-x' instead of '--verbose'.
It makes the t/strip2.sh test succeed on OpenBSD. Then you can remove the
comment "This test needs GNU binutils strip.".

Bruno

Message #32 received at 68179 <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: Bruno Haible <bruno <at> clisp.org>, 68179 <at> debbugs.gnu.org
Subject: Re: [bug#68179] Re: automake-1.16j on OpenBSD
Date: Thu, 22 Feb 2024 22:08:35 +0100

[Message part 1 (text/plain, inline)]

Bruno Haible <bruno <at> clisp.org>, 2024-02-20 12:44:
> Bogdan wrote:
>>    Right. And, as I suspected, nothing in any LIBS, LD*, no libobjc found.
>>    Does it work if you put
>>
>> AC_LANG([Objective C])
>>
>>    somewhere between the lines
>>
>> 	cat >> configure.ac << 'END'
>>
>> and the first
>>
>> 	END
>>
>> following it (i.e., in the 'configure.ac' file) in the test?
>
> No: With this added configure.ac line (before AC_OUTPUT), the
> two tests t/objcxx-minidemo.sh and t/objcxx-deps.sh still fail.
>
>>    If not, do you know any function name that we could use in
>> AC_CHECK_LIB to check for libobjc?


[...]


> ======================================================================
> produces link errors w.r.t. the symbols
>    objc_autoreleasePoolPush
>    objc_autoreleasePoolPop
>    __objc_exec_class
> Is one of them suitable for testing? It depends on the ABI. Looking at
> https://opensource.apple.com/source/objc4/objc4-706/runtime/objc-abi.h.auto.html
> it seems better to choose one of the symbols
>    _objcInit
>    objc_getProperty
>    objc_setProperty
>    objc_setProperty_atomic
>    objc_setProperty_nonatomic
>    ...
>    objc_copyStruct
>    objc_copyCppObjectAtomic
>    _objc_empty_cache
>    ...
>
> But wait! The name of the library 'libobjc' is not standardized either.
>
> I would try to just compile a simple Objective-C++ program and see whether that
> works or not. Such as:


That's what I would expect from Autoconf...
[...]


> =======================================================================
> Missing symbols with clang on OpenBSD:
>    objc_msg_lookup_sender
>    __objc_exec_class
> Missing symbols with clang on Ubuntu:
>    objc_msg_lookup
>    __objc_exec_class


[...]

 Assuming that the library is named "libobjc", I'm attaching a patch
that searches for the above symbols in the library. The tests worked
for me without this, and work after. Feel free to add more rows if the
library name is different.

Gathering the other thread:

> So, in summary, I suggest to use the option '-x' instead of
'--verbose'.
> It makes the t/strip2.sh test succeed on OpenBSD. Then you can
remove the comment "This test needs GNU binutils strip.".


Patch attached.

--
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

[automake-openbsd-objc-mail.diff (text/x-patch, attachment)]

[automake-strip-openbsd-mail.diff (text/x-patch, attachment)]

Message #35 received at 68179 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: bogdro_rep <at> gmx.us
Cc: 68179 <at> debbugs.gnu.org, bruno <at> clisp.org
Subject: Re: bug#68179: Re: automake-1.16j on OpenBSD
Date: Sun, 26 May 2024 16:37:32 -0600

I pushed Bogdan's patches. Listing several functions to look for in
(lib)objc in multiple places doesn't seem ideal, but factoring that out
doesn't seem easy either.

strip -x: no problem.

The general issue:

The AC_PROG_OBJCXX macro already tries to compile a trivial program (of
course), but the test program appears to be valid C++ as well as
ObjC++. What I see in my config.log for, say t/objcxx-deps, is:

| int
| main (void)
| {
| 
|   ;
|   return 0;
| }

That empty line with the ; looks suspicious, but I didn't try to track
it down. (Objc++ is somehow not working with autoconf/automake on my
system, even though it works from the command line. I also see nothing
about Objective anything when I rerun configure. I also seem to vaguely
recall some bug report about this.)

Anyway, I see the objc*.sh automake tests use an #import command to make
the test files valid Objective C(++) but not invalid C(++). I'm not sure
if it makes sense for autoconf to do that, or use some other
Objective-specific construct. Or if that's already happening and I'm
just in some misconfigured situation. --thanks, karl.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.