Author Topic: Porting gengetopt (and another software) leads to strange libtool error  (Read 515 times)

Mentore

  • Sr. Member
  • ****
  • Posts: 286
  • Karma: +19/-0
Hello all,
still here porting software  8)

Strange problem encountered twice today, so I'm thinking I might have some problem in my setup.

I'm trying to port gengetopt 2.23 (git://git.savannah.gnu.org/gengetopt.git). After autoreconf and configure make is able to compile everything (or so it seems) but it fails in building libgengetopt.la with a libtool error:

libtool:   error: object name conflicts in archive: .libs/libgengetopt.lax/gnu.a/D:/Sviluppo/Sorgenti/gengetopt-2.23/src/../gl/.libs/gnu.a


I've just noticed the ... /gnu.a/D:/Sviluppo/Sorgenti/gengetopt ... part. D:\Sviluppo\Sorgenti is the root path for all the source code I work on, so this might be the root cause of the problem.

EDIT: adding this to what makefile reports before throwing the error


sh.exe ../libtool  --tag=CXX   --mode=link /usr/local1510/bin/g++.exe  -O2 -DOS2  -Zhigh-mem -Zomf -lm -lcx -o libgengetopt.la  acceptedvalues.lo argsdef.lo cmdline.lo fileutils.lo
 ggos.lo globals.lo gm.lo gm_utils.lo parser.lo scanner.lo yyerror.lo ../gl/libgnu.la skels/libgen.la
libtool: link: (cd .libs/libgengetopt.lax/gnu.a && ar x "D:/Sviluppo/Sorgenti/gengetopt-2.23/src/../gl/.libs/gnu.a")


I would like to port gengetopt in order to try and port an Atari 2600 emulator.

On a side note, in the next few days I'll test some of my latest ports and upload them on the new Hobbes site. Plus, a DrDialog GUI for grep...

Mentore
Ho
« Last Edit: May 14, 2026, 05:50:48 pm by Mentore »

KO Myung-Hun

  • Full Member
  • ***
  • Posts: 105
  • Karma: +21/-0
Hi/2.

Are you porting gengetopt with a tarball or a git repo ?

I've tried a tarball gengetopt-2.23.tar.xz and succeeded without any problems. What I did is just calling configure script and make like:

Code: [Select]
sh ./configure --prefix=/@unixroot/usr/local --disable-shared --enable-static
make

However, in case of a git repo, I've failed because I have no gengetopt executable and gengen executable after autoreconf -fvi, configure, and make.

I'm using autoconf v2.69, automake v1.18.1, libtool v2.5.4.

Mentore

  • Sr. Member
  • ****
  • Posts: 286
  • Karma: +19/-0
Hi/2.

Are you porting gengetopt with a tarball or a git repo ?

This is one of the quirks. The git repo gave me the same error you got. Then I tried the tarball and everything went fine until the error I reported.

Quote
I've tried a tarball gengetopt-2.23.tar.xz and succeeded without any problems. What I did is just calling configure script and make like:

Code: [Select]
sh ./configure --prefix=/@unixroot/usr/local --disable-shared --enable-static
make

OK, the only difference between your work and mine was that I left shared library enabled - I guess I'll try again later. Thanks!

Mentore

Mentore

  • Sr. Member
  • ****
  • Posts: 286
  • Karma: +19/-0
Hi/2.

Are you porting gengetopt with a tarball or a git repo ?

This is one of the quirks. The git repo gave me the same error you got. Then I tried the tarball and everything went fine until the error I reported.

Quote
I've tried a tarball gengetopt-2.23.tar.xz and succeeded without any problems. What I did is just calling configure script and make like:

Code: [Select]
sh ./configure --prefix=/@unixroot/usr/local --disable-shared --enable-static
make

OK, the only difference between your work and mine was that I left shared library enabled - I guess I'll try again later. Thanks!

Mentore

And yet, another strange error appears. This time, libtool crashes complaining about a "false cr" error in libgnu.la. Attaching the error from make.
I launched the configure script without launching autoreconf -sfi before, to test it.

Here it is:

sh.exe ../libtool  --tag=CC   --mode=compile /usr/local1510/bin/gcc.exe -DHAVE_CONFIG_H -I. -I..   -idirafter u:/usr/include/os2tk45  -O2 -DOS2 -MT dummy.lo -MD -MP -MF $depbase.Tpo -c -o dummy.lo dummy.c &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  /usr/local1510/bin/gcc.exe -DHAVE_CONFIG_H -I. -I.. -idirafter u:/usr/include/os2tk45 -O2 -DOS2 -MT dummy.lo -MD -MP -MF .deps/dummy.Tpo -c dummy.c -o dummy.o
depbase=`echo getopt.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
sh.exe ../libtool  --tag=CC   --mode=compile /usr/local1510/bin/gcc.exe -DHAVE_CONFIG_H -I. -I..   -idirafter u:/usr/include/os2tk45  -O2 -DOS2 -MT getopt.lo -MD -MP -MF $depbase.Tpo -c -o getopt.lo getopt.c &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  /usr/local1510/bin/gcc.exe -DHAVE_CONFIG_H -I. -I.. -idirafter u:/usr/include/os2tk45 -O2 -DOS2 -MT getopt.lo -MD -MP -MF .deps/getopt.Tpo -c getopt.c -o getopt.o
depbase=`echo getopt1.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
sh.exe ../libtool  --tag=CC   --mode=compile /usr/local1510/bin/gcc.exe -DHAVE_CONFIG_H -I. -I..   -idirafter u:/usr/include/os2tk45  -O2 -DOS2 -MT getopt1.lo -MD -MP -MF $depbase.Tpo -c -o getopt1.lo getopt1.c &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  /usr/local1510/bin/gcc.exe -DHAVE_CONFIG_H -I. -I.. -idirafter u:/usr/include/os2tk45 -O2 -DOS2 -MT getopt1.lo -MD -MP -MF .deps/getopt1.Tpo -c getopt1.c -o getopt1.o
sh.exe ../libtool  --tag=CC   --mode=link /usr/local1510/bin/gcc.exe  -O2 -DOS2  -Zhigh-mem -Zomf -lm -lcx -o libgnu.la  dummy.lo getopt.lo getopt1.lo

SYS0109: The pipe has been ended.
copying selected object files to avoid basename conflicts...
libtool: link: false cr .libs/gnu.a dummy.o getopt.o getopt1.o
make[4]: *** [Makefile:660: libgnu.la] Error 1
make[4]: Leaving directory 'D:/Sviluppo/Sorgenti/gengetopt-2.23/gl'
make[3]: *** [Makefile:716: all-recursive] Error 1
make[3]: Leaving directory 'D:/Sviluppo/Sorgenti/gengetopt-2.23/gl'
make[2]: *** [Makefile:611: all] Error 2
make[2]: Leaving directory 'D:/Sviluppo/Sorgenti/gengetopt-2.23/gl'
make[1]: *** [Makefile:689: all-recursive] Error 1
make[1]: Leaving directory 'D:/Sviluppo/Sorgenti/gengetopt-2.23'
make: *** [Makefile:600: all] Error 2


This

libtool: link: false cr .libs/gnu.a dummy.o getopt.o getopt1.o

just puzzles me. I'm starting to believe something in my development toolchain is broken.

Looking at the makefile directives in the listed rows I can see this:

row 600:    $(MAKE) $(AM_MAKEFLAGS) all-recursive (not too surprising, it's the make all directive)

row 611:       && exit 0; \ (am--refresh directive, not too useful I'm afraid)

row 660: install-gengetoptdocDATA: $(gengetoptdoc_DATA)

row 689: $(am__recursive_targets):
   @fail=; \


row 716: ID: $(am__tagged_files)
   $(am__define_uniq_tagged_files); mkid -fID $$unique
tags: tags-recursive


So it seems that looking at the makefile is not helping much (or it's just that I'm not too experienced with makefiles).

Mentore


EDIT: as soon as I gave autoreconf -sfi the usual error appears during make:

libtool:   error: object name conflicts in archive: .libs/libgengetopt.lax/gnu.a/D:/Sviluppo/Sorgenti/gengetopt-2.23/src/../gl/.libs/gnu.a

Can't really fathom what the hell is happening here.
« Last Edit: May 20, 2026, 10:39:31 am by Mentore »

KO Myung-Hun

  • Full Member
  • ***
  • Posts: 105
  • Karma: +21/-0

And yet, another strange error appears. This time, libtool crashes complaining about a "false cr" error in libgnu.la. Attaching the error from make.


Your configure script seemed not to find ar. Check your config.log, find checking for ar line, and see the result.

What are your commands to call configure, and env vars related to build?

Where is -idirafter u:/usr/include/os2tk45 and -DOS2 from ?

If you're using config.site, what is the content of it?

What is your sh.exe? How about trying to various shs such as dash, ash, bash, mksh, pdksh, and so on.

Quote
just puzzles me. I'm starting to believe something in my development toolchain is broken.

Looking at the makefile directives in the listed rows I can see this:

row 600:    $(MAKE) $(AM_MAKEFLAGS) all-recursive (not too surprising, it's the make all directive)

row 611:       && exit 0; \ (am--refresh directive, not too useful I'm afraid)

row 660: install-gengetoptdocDATA: $(gengetoptdoc_DATA)

row 689: $(am__recursive_targets):
   @fail=; \


row 716: ID: $(am__tagged_files)
   $(am__define_uniq_tagged_files); mkid -fID $$unique
tags: tags-recursive


So it seems that looking at the makefile is not helping much (or it's just that I'm not too experienced with makefiles).

I don't understand what you mean. And see Makefile.am not Makefile if possible.


Quote
EDIT: as soon as I gave autoreconf -sfi the usual error appears during make:

libtool:   error: object name conflicts in archive: .libs/libgengetopt.lax/gnu.a/D:/Sviluppo/Sorgenti/gengetopt-2.23/src/../gl/.libs/gnu.a

Can't really fathom what the hell is happening here.

In case of the gengetopt v2.23 tarball, it's not necessary to call autoreconf at all. Anyway, it seems that your autotools are broken. Such an error is caused when a path starting with X:/ is not recognized as an absolute path. You should look into the libtool parts determining if a path is absolute. Usually, they have /* pattern in case.

Mentore

  • Sr. Member
  • ****
  • Posts: 286
  • Karma: +19/-0
Thanks a lot, mate. I'll check all of this as soon as I can - will be helpful for other ports.

I'll keep you guys updated!

Mentore

EDIT May 21: there is indeed some problem.
The configure script doesn't find gawk, gtar, tar, ar and some other program - can't tell why since they are in /usr/bin as they should (and they work).
I tried reinstalling automake, libtool and autoconf - reconfiguring and giving make again still gives the same error.

I don't know where I can hit my head!!!  :( >:(
« Last Edit: May 21, 2026, 12:42:18 pm by Mentore »

KO Myung-Hun

  • Full Member
  • ***
  • Posts: 105
  • Karma: +21/-0
Hi/2.

Are you using config.site? How did you call configure script?

I think, the problems which configure could not find some programs are related to the extention of the executables. If you're using non-ksh such as bash, ash, dash, then it's necessary to set ac_executable_extensions to .exe like:

Code: [Select]
export ac_executable_extensions=".exe"

Put the above line into your script calling configure, or into the config.site file. And set CONFIG_SITE env var to the fully qualified path of config.site.

For SHs, I recommend to use mksh or dash.

Mentore

  • Sr. Member
  • ****
  • Posts: 286
  • Karma: +19/-0
Hi/2.

Are you using config.site? How did you call configure script?

I think, the problems which configure could not find some programs are related to the extention of the executables. If you're using non-ksh such as bash, ash, dash, then it's necessary to set ac_executable_extensions to .exe like:

Code: [Select]
export ac_executable_extensions=".exe"

Put the above line into your script calling configure, or into the config.site file. And set CONFIG_SITE env var to the fully qualified path of config.site.

For SHs, I recommend to use mksh or dash.

Thanks a lot mate, you're a constant source of information!

As per the other items you asked for, I use a CMD file to pre-configure a CMD session with many predefined SET directive. idirafter, for example, is something I found on this forum and actually I found it's not useful if I don't use the OS/2 toolkit. I'm refining this script as long as I see it needs to be corrected, so I guess also these will enter the script itself, while now I understand I can't just rely on it.

As per -DOS2, I use it when I find some problems in porting the original code, so I can edit the code adding an #ifdef __OS2__ to it. Maybe I'm mistaking something?, Dunno, it basically works for me...

I commonly call configure with sh, so maybe this is another possible source of problems.

I'll get my VM back tomorrow and maybe I'll have the time to test it.

Mentore