On Sun, 2021-03-14 at 11:03 +0100, Helge Kruse wrote:
>
> Hello Gerhard,
>
> Am 05.03.2021 um 19:55 schrieb Gerhard Sittig:
> > This is a call for testers. Especially on those platforms which
> > are not exactly mainstream. That is: anything outside of one of
> > the popular Linux distros, which I used in a local setup.
>
> I ran this in MSYS2 on Windows 10.
Thank you for testing. Bonus points for being the first Windows
user who tried this. Haven't heard of Mac users so far either.
> The make step shows a warning
>
> libtool: warning: undefined symbols not allowed in x86_64-w64-mingw32
> shared libraries; building static only
>
> It looks like the warning is a severe problem, since the app_combo.exe
> doesn't output anything about the drivers:
>
> # ./app_combo.exe
> communicating ...
> items:
> list end
Bummer, in this recent iteration of the experiment this is the
only platform which drops the driver items. Probably when another
(static) link phase is done. Which interestingly only happens
with autotools but not with cmake.
Rene probably also saw this with the MXE toolchain. Though IIRC
this was spotted by human inspection of build output, not by
running the result of the build process (in the absence of a
Windows installation).
Have pushed another set of changes, including the "whole archive"
suggestion which Rene dug up. And with preparation (commented
line) when target_link_options() is not available. See commits
aea28a8f3746..75c4a1518306 for details.
> [ ... ]
>
> Because there is a problem with inital approach I wanted to know if the
> mingw compiler in the MSYS2 environment is working with
> __attribute__((constructor)). I created this makefile and could
> successfully build and run the application.
>
> DRVS:=driver_1.o driver_2.o driver_3.o driver_4.o driver_5.o
> OBJS=app_main.o comm.o drivers.o $(DRVS)
>
> app.exe: $(OBJS)
> gcc -g -o app.exe $(OBJS)
Though this isn't "cheating", it's certainly not representing the
problem which motivated the experiment. There is no doubt that
direct linking of all code into an executable in a single step
will work. The issue is when objects get linked into an archive
which gets linked into a library which is referenced by an app.
While the set of objects is highly dynamic and considered
unknown. And the conditions which result in this set of objects
are rather complex and shall never get duplicated. This is the
environment which the libsigrok component is used in. That's what
this experiment tries to reproduce for research. This is the
chain of operations where aggressive optimization breaks the
valid use case of letting a linker collect the specific list of
involved items.
Will have to send a follow-up to the initial CFT, giving more
background information, or pointing out the essential points of
interest. But need a few more days to find the time for that (to
do it properly).
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
