On Sun, Mar 28, 2021 at 11:33:45AM +0200, Pierre Labastie via blfs-dev wrote:
> On Sun, 2021-03-28 at 00:31 +0000, Ken Moffat via blfs-dev wrote:
> > On Sun, Mar 28, 2021 at 12:16:18AM +0000, Ken Moffat wrote:
> > > Trying to bring up a new system (packages current as of a day
> > > ago), I got as far as icewm.
> > >
> > > My previous build used icewm-2.1.2, this attempt was using 2.2.1.
> > > I also note that cmake is now 3.20.0, and that I was initially
> > > adding more options:
> > >
> > > -DCONFIG_LIBRSVG=on \ -DCONFIG_LIBPNG=on
> > > \ -DCONFIG_JPEG=on \
> > >
> > > With those options on a -j8 build the iniital failure was
> > >
> > > [ 80%] Linking CXX executable ../icewmhint cd
> > > /scratch/working/icewm-2.2.1/build/src && /usr/bin/cmake -E
> > > cmake_link_script CMakeFiles/icewmhint.dir/link.txt --verbose=1
> > > /usr/bin/c++ -O3 -march=native -fstack-clash-protection
> > > -D_FORTIFY_SOURCE=2 -fstack-protector-strong -D_GLIBCXX_ASSERTIONS
> > > -O3 -DNDEBUG -Wl,--as-needed
> > > CMakeFiles/icewmhint.dir/icewmhint.cc.o -o ../icewmhint
> > > ../libice.a -lXext -lX11 -flto /usr/bin/ld:
> > > /tmp/icewmhint.F5TdfP.ltrans0.ltrans.o: in function `main':
> > > <artificial>:(.text.startup+0x34): undefined reference to
> > > `YLocale::YLocale(char const*)' /usr/bin/ld:
> > > <artificial>:(.text.startup+0x9a): undefined reference to
> > > `GetArgument(char*&, char const*, char const*, char**&, char**)'
> > > /usr/bin/ld: <artificial>:(.text.startup+0xbc): undefined
> > > reference to `check_help_version(char const*, char const*, char
> > > const*)' /usr/bin/ld: <artificial>:(.text.startup+0x1ff):
> > > undefined reference to `YLocale::~YLocale()' /usr/bin/ld:
> > > <artificial>:(.text.startup+0x245): undefined reference to
> > > `die(int, char const*, ...)' /usr/bin/ld:
> > > <artificial>:(.text.startup+0x292): undefined reference to
> > > `YLocale::~YLocale()' collect2: error: ld returned 1 exit status
> > > make[2]: *** [src/CMakeFiles/icewmhint.dir/build.make:98:
> > > icewmhint] Error 1 make[2]: Leaving directory
> > > '/scratch/working/icewm-2.2.1/build' make[1]: ***
> > > [CMakeFiles/Makefile2:1248: src/CMakeFiles/icewmhint.dir/all]
> > > Error 2 make[1]: *** Waiting for unfinished jobs....
> > >
> > > followed by more than 13000 lines mostly containing similar
> > > reports fro mthe other jobs (lots of other items, such as many
> > > 'clr*' i nthe last report.
> > >
> > > So, I tried omitting those extra lines but the results were very
> > > similar, although starting at a slightly different place:
> > >
> > > [ 79%] Linking CXX executable ../icewmbg cd
> > > /scratch/working/icewm-2.2.1/build/src && /usr/bin/cmake -E
> > > cmake_link_script CMakeFiles/icewmbg.dir/link.txt --verbose=1
> > > /usr/bin/c++ -O3 -march=native -fstack-clash-protection
> > > -D_FORTIFY_SOURCE=2 -fstack-protector-strong -D_GLIBCXX_ASSERTIONS
> > > -O3 -DNDEBUG -Wl,--as-needed CMakeFiles/icewmbg.dir/icewmbg.cc.o
> > > -o ../icewmbg ../libice.a -lXrender -lX11 -lXcomposite -lXdamage
> > > -lXfixes -lXfixes -lgdk_pixbuf_xlib-2.0 -lgdk_pixbuf-2.0
> > > -lgobject-2.0 -lglib-2.0 -lX11 -lXpm -lX11 -lXft -lfribidi
> > > -lXrandr -lXinerama -lXext -lX11 -flto -lXcomposite -lXdamage
> > > -lXfixes -lgdk_pixbuf_xlib-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0
> > > -lglib-2.0 -lXpm -lXft -lfribidi -lXrandr -lXinerama -lXext
> > > /usr/bin/ld: /tmp/icewmbg.LqGNPO.ltrans0.ltrans.o: in function
> > > `YArray<int>::~YArray()': <artificial>:(.text+0x87): undefined
> > > reference to `vtable for YBaseArray' /usr/bin/ld:
> > > <artificial>:(.text+0x8c): undefined reference to
> > > `YBaseArray::clear()' /usr/bin/ld:
> > > /tmp/icewmbg.LqGNPO.ltrans0.ltrans.o: in function
> > > `YArray<YColor>::~YArray()':
> > >
> > > (about 400 lines from that file before Error 1.)
> > >
> > > So, I start to assume that this might be caused by newer cmake.
> > > But since that has been working fine up to now, I went for the
> > > previous version of icewm which I had handy (2.1.2, I did not have
> > > 2.2.0 or 2.2.1) and that built without problems.
> > >
> > > I've said before that I think using cmake for icewm is a
> > > less-tested path (and I think cmake is horrible), but I've now got
> > > a version of icewm installed so I'll continue my build (currently
> > > on node.js so I can't yet use firefox to see if there is anything
> > > relevant).
> > >
> > > I'll maybe revisit this. But given what else I intend to do, I
> > > very much doubt that I'll look at this for the next week!
> > >
> > I was about to suspend another machine, so I tried a quick google on
> > that (nothing) followed by an unlogged -j4 build of 2.2.1 matching
> > the book using cmake-3.19.5 and -j4 : that seems to have failed at
> > the same place [89%] followed by a lot of similar output.
> >
> > Seems to me that the book is definitely broken, and yet it was
> > apparently working on 17th March. Tim, any thoughts ?
>
> I've tried building icewm today at -j5 on a 4-core processor with HT.
> It worked.
>
> There might be a race condition when building libice.a (since the missing
> symbols should be there). You might want to remove libice.a and run make -j1.
> Otherwise, it'd be interesting to run nm -C libice.a and see whether the
> missing
> symbols are there.
>
> That's all I can think of for now...
>
> Pierre
>
Pierre, thanks for that comment.
On the first attempt (with the extra defines) I see the followign in
the log:
[ 64%] Linking CXX static library ../libice.a
cd /scratch/working/icewm-2.2.1/build/src && /usr/bin/cmake -P
CMakeFiles/ice.dir/cmake_clean_target.cmake
cd /scratch/working/icewm-2.2.1/build/src && /usr/bin/cmake -E
cmake_link_script CMakeFiles/ice.dir/link.txt --verbose=1
/usr/bin/ar qc ../libice.a CMakeFiles/ice.dir/udir.cc.o
CMakeFiles/ice.dir/upath.cc.o CMakeFiles/ice.dir/yapp.cc.o
CMakeFiles/ice.dir/yxapp.cc.o CMakeFiles/ice.dir/ytimer.cc.o
CMakeFiles/ice.dir/yprefs.cc.o CMakeFiles/ice.dir/ywindow.cc.o
CMakeFiles/ice.dir/ypaint.cc.o CMakeFiles/ice.dir/ypopup.cc.o
CMakeFiles/ice.dir/ycursor.cc.o CMakeFiles/ice.dir/ysocket.cc.o
CMakeFiles/ice.dir/ypaths.cc.o CMakeFiles/ice.dir/ypipereader.cc.o
CMakeFiles/ice.dir/yxembed.cc.o CMakeFiles/ice.dir/yconfig.cc.o
CMakeFiles/ice.dir/yfont.cc.o CMakeFiles/ice.dir/ypixmap.cc.o
CMakeFiles/ice.dir/yimage2.cc.o CMakeFiles/ice.dir/yimage_gdk.cc.o
CMakeFiles/ice.dir/yximage.cc.o CMakeFiles/ice.dir/ycolor.cc.o
CMakeFiles/ice.dir/ytooltip.cc.o CMakeFiles/ice.dir/ylocale.cc.o
CMakeFiles/ice.dir/yarray.cc.o CMakeFiles/ice.dir/yfileio.cc.o
CMakeFiles/ice.dir/ytime.cc.o CMakeFiles/ice.dir/mstring.cc.o
CMakeFiles/ice.dir/ref.cc.o CMakeFiles/ice.dir/logevent.cc.o
CMakeFiles/ice.dir/misc.cc.o CMakeFiles/ice.dir/yfontxft.cc.o
/usr/bin/ar: CMakeFiles/ice.dir/udir.cc.o: plugin needed to handle lto object
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/usr/bin/ranlib ../libice.a
/usr/bin/ranlib: ../libice.a(udir.cc.o): plugin needed to handle lto object
make[2]: Leaving directory '/scratch/working/icewm-2.2.1/build'
make[1]: Entering directory '/scratch/working/icewm-2.2.1/build'
[ 64%] Built target ice
whereas on the successful 2.1.2 build there is no mention of libice.
In theory plugins should have been working for years, and nothing in
that area has changed, but exceot for icewm I don't use lto because
packages that should benefit from the longer build (mozilla
packages) get rebuilt monthly and the extra build time seems a
waste.
For icewm, the specification of LTO was needed to get the cmake
build to work, maybe the fix for that in the release notes altered
this (and I still think that we should use configure for this
package). But this is a very low priority for me.
I'm currently building qtwebengine, I'll probably leave this for the
moment.
ĸen
--
On average, the Panda feeds for 15 hours a day. This is the
same as an adult at home under quarantine, which is why we call
it a "Pandemic".
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
