groff compiles successfully, but when src/utils/pfbtops is linked, the process aborts with: CC -J2 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip35:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035 -FE:eliminate_duplicate_inline_copies:template_in_elf_section -woff 1174,1183,1185,1552,3968,3970 -Wl,-v,-s,-x,-n32,-mips4,-rdata_shared,-allow_jump_at_eop,-rpath,/opt/portage/usr/lib:/opt/portage/lib -L/opt/portage/usr/lib -L/opt/portage/lib -o pfbtops pfbtops.o /usr/opt/portage/var/tmp/portage/sys-apps/groff-1.19.2-r2/work/groff-1.19.2/src/libs/libgroff/libgroff.a -lm <...> ld32: ERROR 33 : Unresolved text symbol "getopt_long" -- 1st referenced by pfbtops.o. <...> ld32: INFO 152: Output file removed because of error. make[2]: *** [pfbtops] Error 2 make[2]: Leaving directory `/usr/opt/portage/var/tmp/portage/sys-apps/groff-1.19.2-r2/work/groff-1.19.2/src/utils/pfbtops' make[1]: *** [src/utils/pfbtops] Error 2 make[1]: Leaving directory `/usr/opt/portage/var/tmp/portage/sys-apps/groff-1.19.2-r2/work/groff-1.19.2' make: *** [all] Error 2 * ERROR: sys-apps/groff-1.19.2-r2 failed: * (no error message) * * Call stack: * ebuild.sh: 49: <call src_compile> * environment:2849: emake || die ... so it looks as if the other components of groff correctly detect when native getopt_long functions are not available, and use their own implementation. The utilities (or, at least, pfbtops) however don't do this, and so the build fails. This failure blocks 'emerge system' (unless entered into package.provided) and blocks the installation of sys-apps/man-1.6f-r1.
(Note that pfbtops.c is actually plain C code - yet the makefile builds it with the C++ compiler and flags. Correcting this doesn't fix the error, but does remove some notices...)
IIRC, this problem was solved for NetBSD's pkgsrc on IRIX - the problem related to IRIX having a <getopt.h>, but this not being GNU-compliant, which was confusing packages' checks against _GETOPT_H. However, this was probably fixed in the libnbcompat wrapper library, so this may not be useful here...
To confirm, if the single line referencing 'pfbtops' is removed from the top-level Makefile, then everything builds successfully. (As as aside, I'd be *really* useful for package debugging if the 'econf' stuff was run within src_unpack rather than src_compile - so that if you need to 'ebuild unpack' a package, alter the Makefile, then 'ebuild compile' it, the compilation stage doesn't overwrite your changes!)
Still broken in groff-1.19.2-r3
If building with USE="X", then xtotroff also fails due to the same getopt_long error.
... and, strangely, gxdirview tries to link against libXaw.so.9, whereas x11-libs/libXaw only installs libXaw.so.[678]. This may, of course, be a libXaw problem...
* gxditview libXaw seems to have an off-by-one error: Bug 236545
is the getopt package of any help to solve this getopt_long problem?
I've always had getopt-1.1.4 installed, and it doesn't affect groff's (failure to) build. The only currently solution seems to be an irix-specific patch to prevent pfbtops and xtotroff from being built :( (getopt-1.1.4 includes a getopt-long shell command, but doesn't provide a library function) It may be that this package was one that benefitted from libgnugetopt, though...
(In reply to comment #0) > /usr/opt/portage/var/tmp/portage/sys-apps/groff-1.19.2-r2/work/groff-1.19.2/src/libs/libgroff/libgroff.a > -lm > <...> > ld32: ERROR 33 : Unresolved text symbol "getopt_long" -- 1st referenced by > pfbtops.o. This is strange: As of groff-1.19.2-r3, libgroff.a does contain both getopt.o and getopt1.o, which are the whole getopt/getopt_long implementation, being compiled with -D__GETOPT_PREFIX=groff_, even on Linux - there is nothing conditional here. And in pfbtops.c, there is: 29 30 #define __GETOPT_PREFIX groff_ 31 #include <getopt.h> 32 So getopt_long really shouldn't be undefined there...
> So getopt_long really shouldn't be undefined there... > Bear in mind that, on IRIX, the system <getopt.h> *isn't* GNU getopt, and has no concept of getopt_long. IRIX needs a separate getopt library. I've modified the ebuild to use gnulib, but the process still fails: cc -I. -I. -I/usr/opt/gentoo/var/tmp/portage/sys-apps/groff-1.19.2-r3/work/groff-1.19.2/src/include -I/usr/opt/gentoo/var/tmp/portage/sys-apps/groff-1.19.2-r3/work/groff-1.19.2/src/include -DHAVE_CONFIG_H -I/opt/gentoo/usr/lib32/gnulib/include -I/opt/gentoo/usr/include -c pfbtops.c CC -L/opt/gentoo/usr/lib32/gnulib/lib32 -o pfbtops pfbtops.o /usr/opt/gentoo/var/tmp/portage/sys-apps/groff-1.19.2-r3/work/groff-1.19.2/src/libs/libgroff/libgroff.a -lgnu -lm ld32: WARNING 84 : /opt/gentoo/usr/lib32/gnulib/lib32/libgnu.a is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/mips4/libm.so is not used for resolving any symbol. ld32: ERROR 33 : Unresolved text symbol "getopt_long" -- 1st referenced by pfbtops.o. Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: INFO 152: Output file removed because of error. make[2]: *** [pfbtops] Error 2 make[2]: Leaving directory `/usr/opt/gentoo/var/tmp/portage/sys-apps/groff-1.19.2-r3/work/groff-1.19.2/src/utils/pfbtops' make[1]: *** [src/utils/pfbtops] Error 2 make[1]: Leaving directory `/usr/opt/gentoo/var/tmp/portage/sys-apps/groff-1.19.2-r3/work/groff-1.19.2' make: *** [all] Error 2 ... chiefly because gnulib's getopt *also* seems to omit getopt_long: nm /opt/gentoo/usr/lib32/gnulib/lib32/libgnu.a | grep getopt_long [2] | 0| 56|FUNC |GLOB |DEFAULT |5 |rpl_getopt_long [4] | 64| 60|FUNC |GLOB |DEFAULT |5 |_getopt_long_r [6] | 128| 56|FUNC |GLOB |DEFAULT |5 |rpl_getopt_long_only [7] | 192| 60|FUNC |GLOB |DEFAULT |5 |_getopt_long_only_r
Ah - I missed the whole __GETOPT_PREFIX mechanism. The problem here is that I had to use "append-cflags -I"${EPREFIX}"/usr/$(get_libdir)/gnulib/include" in the build, as on IRIX <stdint.h> #errors out if used to build C++ code, and the gnulib headers unconditionally include this header. The problematic source file just happens to be built with $CXX <sigh>
(The error from configure is: checking whether we are using the GNU C++ compiler... no checking whether CC accepts -g... yes checking that C++ compiler can compile simple program... yes checking that C++ static constructors and destructors are called... yes checking that header files support C++... no configure: error: header files do not support C++ (if you are using a version of gcc/g++ earlier than 2.5, you should install libg++) ... with the following in config.log: configure:3307: checking that header files support C++ configure:3340: CC -o conftest -I/opt/gentoo/usr/include -I/opt/gentoo/usr/lib32/gnulib/include -L/opt/gentoo/usr/lib32/gnulib/lib32 conftest.cpp -lgnu >&5 cc-1035 CC: ERROR File = /usr/include/stdint.h, Line = 5 #error directive: This header file is to be used only for c99 mode compilations #error This header file is to be used only for c99 mode compilations ^ cc-1020 CC: ERROR File = /opt/gentoo/usr/lib32/gnulib/include/stdlib.h, Line = 58 The identifier "int32_t" is undefined. int32_t *fptr; /* Front pointer. */ ^ cc-1020 CC: ERROR File = /opt/gentoo/usr/lib32/gnulib/include/stdlib.h, Line = 59 The identifier "int32_t" is undefined. int32_t *rptr; /* Rear pointer. */ ^ cc-1020 CC: ERROR File = /opt/gentoo/usr/lib32/gnulib/include/stdlib.h, Line = 60 The identifier "int32_t" is undefined. int32_t *state; /* Array of state values. */ ^ cc-1020 CC: ERROR File = /opt/gentoo/usr/lib32/gnulib/include/stdlib.h, Line = 64 The identifier "int32_t" is undefined. int32_t *end_ptr; /* Pointer behind state table. */ ^ 5 errors detected in the compilation of "conftest.cpp". configure:3347: $? = 2 configure: failed program was: | | /* confdefs.h. */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | /* end confdefs.h. */ | | | #include <stdio.h> | | | int | main () | { | | | fopen(0, 0); | | | ; | return 0; | } | configure:3361: result: no configure:3363: error: header files do not support C++ (if you are using a version of gcc/g++ earlier than 2.5, you should install libg++) )
This patch should fix gnulib's stdlib.h - but this files does start with a warning that it is auto-generated and shouldn't be edited: +++++ cut here +++++ --- /opt/gentoo/usr/lib32/gnulib/include/stdlib.h.dist +++ /opt/gentoo/usr/lib32/gnulib/include/stdlib.h @@ -49,7 +49,11 @@ #endif #if 0 || !0 -# include <stdint.h> +# if defined(__sgi) && !defined(__c99) +typedef signed int int32_t; +# else +# include <stdint.h> +# endif #endif #if !0 +++++ cut here +++++ ... with this the configure test passes. However, the build still fails complaining that getopt_long can't be resolved :(
(In reply to comment #11) > > So getopt_long really shouldn't be undefined there... > > > > Bear in mind that, on IRIX, the system <getopt.h> *isn't* GNU getopt, and has > no concept of getopt_long. IRIX needs a separate getopt library. Err: groff *does* ship with *complete* GNU getopt, and should not use any system getopt.h at all (on HP-UX fex getopt.h isn't GNU getopt either). > > I've modified the ebuild to use gnulib, but the process still fails: For getopt/getopt_long, this is not necessary, even if there were *no* getopt on the system at all. Can you try to preprocess the pfbtops.c similar to the build, to see why it uses getopt_long while it should use groff_getopt_long?
Created attachment 198264 [details] Preprocessor output from pfbtops.c I notice that this file is compiled with 'cc' (which succeeds), but is then linked against libgroff.a with 'CC' (which fails) - surely a mistake?
Created attachment 198265 [details] 'nm' output for libgroff.a The relevant entries seem to be: Symbols from ../../libs/libgroff/libgroff.a[getopt.o]: [10] | 352| 216|FUNC |LOCL |DEFAULT |5 |_getopt_initialize [13] | 576| 4384|FUNC |GLOB |DEFAULT |5 |_getopt_internal_r [21] | 4960| 128|FUNC |GLOB |DEFAULT |5 |_getopt_internal [22] | 5088| 64|FUNC |GLOB |DEFAULT |5 |groff_getopt [36] | 8| 0|STAT |LOCL |DEFAULT |MIPS_DATA|getopt_data [38] | 352| 216|STAT |LOCL |DEFAULT |MIPS_TEXT|_getopt_initialize Symbols from ../../libs/libgroff/libgroff.a[getopt1.o]: [2] | 0| 56|FUNC |GLOB |DEFAULT |5 |groff_getopt_long [3] | 0| 0|FUNC |GLOB |DEFAULT |UNDEF |_getopt_internal [4] | 64| 60|FUNC |GLOB |DEFAULT |5 |_getopt_long_r [5] | 0| 0|FUNC |GLOB |DEFAULT |UNDEF |_getopt_internal_r [6] | 128| 56|FUNC |GLOB |DEFAULT |5 |groff_getopt_long_only [7] | 192| 60|FUNC |GLOB |DEFAULT |5 |_getopt_long_only_r ... which looks okay to me.
Created attachment 198269 [details] Preprocessor output from pfbtops.c ... with line directives this time - oops.
Weirdly, if I append "-D__GETOPT_PREFIX=groff_" to my CFLAGS, the source compiles successfully... Why is the __GETOPT_PREFIX define not being output by the preprocessor??!?
... with: if [[ ${CHOST} == *-irix* ]]; then append-cppflags -D__GETOPT_PREFIX=groff_ fi ... added to the src_compile() stage of the ebuild, groff builds successfully. I don't have a clue why this is needed, though. I have over 250 portage packages installed on this system, and no others are similarly broken. However, this build is broken on multiple IRIX machines that I'm testing with.
Created attachment 198291 [details, diff] patch to define __GETOPT_PREFIX earlier in pfbtops.c Seems like IRIX' stdio.h does include getopt.h already. So even if the local getopt.h is found, the #define __GETOPT_PREFIX in pfbtops.c comes too late. Will commit this patch when you confirm it does help.
This patch fixes pdftops, but xtotroff is also affected and likewise needs patching...
fixed in r48560.
