Symmetry elements as an off file

[Roger Kaufman]

Hi Adrian,

On 5/15/2023 3:21 AM, Adrian Rossiter wrote:
> A while back I thought about writing an off2off program, that would
> create
> an OFF file marked up with display elements, but realised that almost
> anything I would use it for I would probably be better of using the
> current display/export programs. This is because vertices and edges would
> not be smooth, labels would rotate with the model, and symmetry elements
> need lots of invisible elements included, that might not be treated
> as invisible by the program that processed the model.
>
> The symmetry elements model in Antiprism correponds to an OFF models,
> and it should be straightforward to create and output this model from
> C++. See DisplaySymmetry in base/displaypoly.cc.

I started a program taking code from other programs like off2dae and
vw_glut.cc. I had trouble setting show_axes (and the others) because
sym_defs is private so I set them in main.

The program doesn't crash but it doesn't change the model. The aim is to
be able to add the symmetry elements while being able to delete all the
original elements. This implies it generates the symmetry geom that will
be appended the input geom.

I wanted to do this in a way nothing else would need to be changed if
possible, but I think it wasn't intended to do this. The program could
be put in src_extra or I could keep it privately. Comments in the help
need to mention invisible elements are involved.

Roger

[Adrian Rossiter]

Hi Roger

On Tue, 16 May 2023, Roger Kaufman wrote:
> I started a program taking code from other programs like off2dae and
> vw_glut.cc. I had trouble setting show_axes (and the others) because sym_defs
> is private so I set them in main.
>
> The program doesn't crash but it doesn't change the model. The aim is to be
> able to add the symmetry elements while being able to delete all the original
> elements. This implies it generates the symmetry geom that will be appended
> the input geom.
>
> I wanted to do this in a way nothing else would need to be changed if
> possible, but I think it wasn't intended to do this. The program could be put
> in src_extra or I could keep it privately. Comments in the help need to
> mention invisible elements are involved.

The code just needs a minor amendment to the part that appends the
symmetry elements geometry

vector<SceneGeometry>::iterator geo;
for (geo = scen.get_geoms().begin(); geo != scen.get_geoms().end();
++geo) {
if (DisplaySymmetry *sym =
dynamic_cast<DisplaySymmetry *>(geo->get_sym())) {
sym->set_show_axes(opts.show_axes);
sym->set_show_mirrors(opts.show_mirrors);
sym->set_show_rotrefls(opts.show_rotrefls);

sym->geom_changed();
geom.append(sym->get_disp_geom());
}
}


If it is helpful for this to be included in Antiprism, then maybe
it could be an off_util option, rather than a separate program. The
option could simply replace the current geometry (which would respect
the off_util sequential processsing). To implement -x, you could allow
letters vef in the same option to retain these elements (i.e. an
argument "a" would output all the symmetry elements and nothing
of the base model "avef" would output all the symmetry elements and
all of the base model).

Adrian.
--
Adrian Rossiter
adr...@antiprism.com
http://antiprism.com/adrian

[Wagyx Xygaw]

Hi Adrian and Roger,

I am not used at all with this symmetry stuff. I can't wrap my head around what the issue is, its complexity and the solution you are discussing.
I kind of get a rough impression of the main points from using Stella And Antiprism but code wise, I don't get how the symmetries of a given shape are found efficiently, used in the model creation or serves in its transformation.
I think I am lacking the proper background in maths and CS. Would you have a good set of resources for me to study ?
Thanks.

[Roger Kaufman]

Hi Adrian,

That let me move forward. Thanks. This statement was then redundant
sym->geom_changed();

I attached the standalone program.

I went a little differently. For v e and f the models elements are made
invisible. In that way it is hiding the elements but not deleting them
so e.g. vertices can be hidden while faces and edges are displayed. I
have 'a' to delete the whole model, but it is not like vef which would
make the whole model invisible.

./off_sym -s a tet -x v | antiview

-s matches that of antiview and off2vrml. -s and -S are being used in
off_util and -x works differently there. There is no way to delete
vertices in off_util (-x v just removes colors) which we probably didn't
do since it deletes the whole model!

I suppose it could be added in to off_util with the extra options for
vef, but I'd worry it might interfere with other off_util options or
give unexpected results. If faces are deleted (-x f) after symmetry
elements are generated, they would also be deleted. If it were in
off_util the model elements (if not specified) should only be rendered
invisible but not deleted so that anything involving the model would
still work as expected.

./off_sym -s a tet | off_util -A f100,200,300 | antiview

Note that the online viewer displays the model with symmetry elements
properly.

Roger

[Adrian Rossiter]

Hi Wagyx

On Tue, 16 May 2023, Wagyx Xygaw wrote:
> I am not used at all with this symmetry stuff. I can't wrap my head around
> what the issue is, its complexity and the solution you are discussing.
> I kind of get a rough impression of the main points from using Stella And
> Antiprism but code wise, I don't get how the symmetries of a given shape
> are found efficiently, used in the model creation or serves in its
> transformation.
> I think I am lacking the proper background in maths and CS. Would you have
> a good set of resources for me to study ?

I made a short overview of the symmetry features available in the
Antiprism programs, which illustrates where symmetry is useful (and,
since writing it, programs like poly_form and canonical now also
make use of symmetry, to constrain the solution model to have the
symmmetry of the base model.)

https://www.antiprism.com/examples/250_topics/100_symmetry/imagelist.html

I have tried to define the terms needed to describe the symmetry options
in relatively simple terms, but it isn't meant to be a tutorial on
symmetry itself.


In Antiprism, the symmetry group is found as follows. A convex hull is
made. The edges and vertices of this are a (mathemetical) graph, and some
(third-party) code finds the symmetries of this graph

https://en.wikipedia.org/wiki/Graph_automorphism

These can be converted to Euclidean transformations, that may be
symmetries of the base model. These transformations are checked and
analysed and the symmetry group of the base model is inferred.


The overview covers some uses of symmetry in creating models.

For its use in transformation, when an iterative program constrains
symmetry, say a vertex lies on a plane of mirror symmetry in the base
model, then the iteration can never allow it to leave that plane, because
that would require a new vertex to be its reflection in that mirror.


There is a chapter on symmetry in Polyhedra by Peter R Cromwell, which
was an introduction to symmetry for me and an inspiration to know more

https://www.amazon.com/Polyhedra-Peter-R-Cromwell/dp/0521664055

I followed this up by working through Contempory Abstract Algebra
by Joseph Gallian, which is an undergraduate level maths textbook

https://www.amazon.com/-/es/Joseph-Gallian/dp/0367651785

It covers a lot of relevent group theory and linear algebra. I found it
really good for self-study, but it did take a few months to work through!

[Adrian Rossiter]

Hi Roger

On Tue, 16 May 2023, Roger Kaufman wrote:
> I suppose it could be added in to off_util with the extra options for vef,
> but I'd worry it might interfere with other off_util options or give
> unexpected results. If faces are deleted (-x f) after symmetry elements are
> generated, they would also be deleted. If it were in off_util the model
> elements (if not specified) should only be rendered invisible but not deleted
> so that anything involving the model would still work as expected.
>
> ./off_sym -s a tet | off_util -A f100,200,300 | antiview
>
> Note that the online viewer displays the model with symmetry elements
> properly.

Regarding off_util, when an option is specified the current model is
processed before movig on to the next option, and so if an option does
something that involves deleting/renumbering elements then the user
needs to take this into account before specifying the next option. An
option that inserts a symmetry element model is not especially
different in this regard.

However, the option doesn't entirely fit with off_util, and your example
command highlights this, because the output has no geometrical value in
itself, but is instead just a visual guide for a human viewer. Maybe it
could go in off_report as a visual report, but that doesn't seem right
either, as all other reports are text.

Also... I am keen to keep the number of executables down, mostly to keep
the documentation more usable. If a smaller feature can be implemented
with a single simple option, then it could be tucked away in a *_util
program, and doesn't have the same prominence in the list of programs
as a more full featured program, that can also benefit from having its
own documentation page. On the other hand, as soon as something needs a
set of options, then it is probably better as a separate program with its
own documentation page.

I don't see an obvious choice here. Perhaps, if you want to distribute it
because you want it to be easily available to people who are creating
content for the web viewer, then maybe it will end up with more options
relating to the viewer, and should be an 'extra' program (and might not be
called off_sym). Or, if it is just somethig that will be run as it is for
the viewer, using instructions provided elsewhere, and it is unlikely to
be run for any other purpose, then off_util might be better.

Anyway, whatever you think best!

[Roger Kaufman]

Hi Adrian,

On 5/17/2023 8:31 AM, Adrian Rossiter wrote:
> I don't see an obvious choice here. Perhaps, if you want to distribute it
> because you want it to be easily available to people who are creating
> content for the web viewer, then maybe it will end up with more options
> relating to the viewer, and should be an 'extra' program (and might
> not be
> called off_sym). Or, if it is just somethig that will be run as it is for
> the viewer, using instructions provided elsewhere, and it is unlikely to
> be run for any other purpose, then off_util might be better.
>
> Anyway, whatever you think best!

There are a couple things to consider. I tried to alter the program to
use ProgramOpts instead of ViewOpts and process the input geoms like
off_util, in a test to see if I can just make this a function to put in
off_util.

There is convenience in Viewopts so in main it would have to be
something like this. But this wouldn't work because viewopts wants to
read the geoms in set_view_val()

void add_sym_elems(string elem_str) {
...
scen.set_geom(opts.geom); // there is no set_geom()
ViewOpts viewopts("viewopts"); (does this even make sense)
viewopts.set_view_vals(scen);

I was really trying to have to change base code but I think this was
made for a specific use.

Once symmetry adornments are on a model, changing face colors would
change the adornments. This is really something that would be put on at
the end of whatever was being done when the model is in its final form.

Do you think there are any other symmetry related uses that could go in
the program to make it worth adding a new one?

Or I could keep the program for myself. I had in the past thought about
putting some of my utility programs in a git project. They are all
dependent on Antiprism. Or maybe I could put them in my own fork in
antiprism_rk, like in src_rk. Then they would be available to anyone who
used the fork, but not have to go over to the master.

There's too many options :)

Roger

[Adrian Rossiter]

Hi Roger

On Wed, 17 May 2023, Roger Kaufman wrote:
> On 5/17/2023 8:31 AM, Adrian Rossiter wrote:
>> I don't see an obvious choice here. Perhaps, if you want to distribute it
>> because you want it to be easily available to people who are creating
>> content for the web viewer, then maybe it will end up with more options
>> relating to the viewer, and should be an 'extra' program (and might not be
>> called off_sym). Or, if it is just somethig that will be run as it is for
>> the viewer, using instructions provided elsewhere, and it is unlikely to
>> be run for any other purpose, then off_util might be better.
>>
>> Anyway, whatever you think best!
>
> There are a couple things to consider. I tried to alter the program to use
> ProgramOpts instead of ViewOpts and process the input geoms like off_util, in
> a test to see if I can just make this a function to put in off_util.

...

> I was really trying to have to change base code but I think this was made for
> a specific use.

The following code sets up a minimal scene to generate the symmetry
element geometry, and avoids ViewOpts.

Geometry make_sym_elems_geom(const Geometry &geom, bool show_axes,
bool show_mirrors, bool show_rotrefls)
{
DisplaySymmetry disp_sym;
disp_sym.set_show_axes(show_axes);
disp_sym.set_show_mirrors(show_mirrors);
disp_sym.set_show_rotrefls(show_rotrefls);

Scene scen;
SceneGeometry sc_geom;
sc_geom.set_scene(&scen);
sc_geom.set_sym(disp_sym);
sc_geom.set_geom(geom);
scen.add_geom(sc_geom);

auto *sym = dynamic_cast<DisplaySymmetry
*>(scen.get_geoms()[0].get_sym());
return sym->get_disp_geom();

}


> Do you think there are any other symmetry related uses that could go in the
> program to make it worth adding a new one?

I can't think of any.

> Or I could keep the program for myself. I had in the past thought about
> putting some of my utility programs in a git project. They are all dependent
> on Antiprism. Or maybe I could put them in my own fork in antiprism_rk, like
> in src_rk. Then they would be available to anyone who used the fork, but not
> have to go over to the master.

Another option is to have just the program source in the repository, and
a build script could download Antiprism, and build and install it into a
parallel directory (as required) then build your source and link
statically with the Antiprism library. This avoids installing a second
copy of the Antiprism libary, and would make the binaries resistant to
changes in Antiprism in the case that the library had the same name.

I tend to have this kind of setup when when making binary packages, as
it works well with cross-compilation, as the parallel directories can
contain libraries that were built for the target system.

[Roger Kaufman]

Hi Adrian,

On 5/19/2023 2:04 AM, Adrian Rossiter wrote:

The following code sets up a minimal scene to generate the symmetry
element geometry, and avoids ViewOpts.

...

Thanks for the code. The way its done in antiview is that all the separate models get their own symmetry elements.

off_color -v none -e none -f none pri5 | off_trans -T -1,0,0 > pri5.off
off_color -v yellow -e darkgreen -f red pri3 | off_trans -T 1,0,0 > pri3.off
antiview -s a pri5.off pri3.off

I was thinking of keeping it like this but having it work on one geometry has some potential.

Do you think there are any other symmetry related uses that could go in the program to make it worth adding a new one?

I was wondering if it could work with sub-symmetry and it can. If it is a valid sub-symmetry it creates the symmetry elements using model sym_XX and is appended to the model. Doing so realigns the model using the -y option taken out of off_trans.

off_trans -R 10,20,-30 ant12 | off_sym -s a -y D3v | antiview

The starting model alignment can be restored with -z (but will wipe out the alignments if used)

off_trans -R 10,20,-30 ant12 | off_sym -s a -y D3v -z | antiview

The symmetry figure looks good in the online viewer but if faces are hidden then it will disappear as its now part of the model.

off_util j90 | off_sym -s a -x f | webview.py -e 0.1 -v 0.15 -B 000000

Extended helps are borrowed from off_util -H help

-H        Symmetry help and Symmetry Model help (from off_util -H help)

A symmetry listing that includes free rotations and free translations. In off_trans -y will say for what sub-symmetries they aren't allowed, but there is no reference for the ones that allow it. But I noticed they are listed for compounds in the poly_kscope program so I linked them similarly.

off_sym -L pri3

[symmetry]
type = D3h
[symmetry_subgroups]
C1,1	x full  rotation		x space translation
C2,1	x axial rotation		x space translation
C2v,1	x axial translation
C3,1	x axial rotation		x space translation
C3h,1	x axial rotation
C3v,1	x axial translation
Cs,2	x axial rotation		x space translation
D3,1
D3h,1

-y behaves like in off_trans

off_sym -s a -y C4v,0,:2 j85 | poly_kscope -s D2 | antiview

Or I could keep the program for myself. I had in the past thought about putting some of my utility programs in a git project. They are all dependent on Antiprism. Or maybe I could put them in my own fork in antiprism_rk, like in src_rk. Then they would be available to anyone who used the fork, but not have to go over to the master.

Another option is to have just the program source in the repository, and
a build script could download Antiprism, and build and install it into a
parallel directory (as required) then build your source and link
statically with the Antiprism library. This avoids installing a second
copy of the Antiprism libary, and would make the binaries resistant to
changes in Antiprism in the case that the library had the same name.

I tend to have this kind of setup when when making binary packages, as
it works well with cross-compilation, as the parallel directories can
contain libraries that were built for the target system.

Link statically to create standalone programs? I was wondering if this was still possible. I have programs I wrote for Hedron that I haven't maintained because I can no longer distribute the standalone executables. Here is my makefile that refers to my base directory

LIBS = /home/roger/antiprism_rk/base/.libs/libantiprism.a $(COMMON_LIB)
CPPFLAGS = -I/usr/local/include -I/home/roger/antiprism_rk/base
CXX = g++ -Wall -Wextra -std=c++14

If this is possible I'd like to know how to do it both in the linux build and the cross compiled programs. I cross compile in the cygwin environment but might it be possible to cross compile in ubuntu for the windows executables?

Being able to do this would be a step closer to creating new repositories. The requirement for the Antiprism package would still be there (and be documented to get it) but then the programs generated could be distributed.

Roger

[Adrian Rossiter]

Hi Roger

On Fri, 26 May 2023, Roger Kaufman wrote:
> On 5/19/2023 2:04 AM, Adrian Rossiter wrote:
>> The following code sets up a minimal scene to generate the symmetry
>> element geometry, and avoids ViewOpts.
>> ...
>
> Thanks for the code. The way its done in antiview is that all the separate
> models get their own symmetry elements.

...

> I was thinking of keeping it like this but having it work on one geometry has
> some potential.

If the user wants to see the symmetry of the combined model then this
can be done with off_util. The same situation exists with element
number labels.

> Extended helps are borrowed from off_util -H help
>
> -H        Symmetry help and Symmetry Model help (from off_util -H help)
>
> A symmetry listing that includes free rotations and free translations. In
> off_trans -y will say for what sub-symmetries they aren't allowed, but there
> is no reference for the ones that allow it. But I noticed they are listed for
> compounds in the poly_kscope program so I linked them similarly.

Err, yes. They don't seem to be listed in the documentation anywhere! I'll
review that. Maybe I'll make a symmetry documentation page based on the
website symmetry topic page (which also doesn't list them, but does give
an example that uses a free translation).

>> Another option is to have just the program source in the repository, and
>> a build script could download Antiprism, and build and install it into a
>> parallel directory (as required) then build your source and link
>> statically with the Antiprism library. This avoids installing a second
>> copy of the Antiprism libary, and would make the binaries resistant to
>> changes in Antiprism in the case that the library had the same name.
>>
>> I tend to have this kind of setup when when making binary packages, as
>> it works well with cross-compilation, as the parallel directories can
>> contain libraries that were built for the target system.
>
> Link statically to create standalone programs? I was wondering if this was
> still possible. I have programs I wrote for Hedron that I haven't maintained
> because I can no longer distribute the standalone executables. Here is my
> makefile that refers to my base directory

As I recall, the main issue is that it can be difficult to build
a binary that depends on both static and dynamic libraries. I think
I sometimes specify the static library as an object file during linking,
and I believe it can also be done with options that act like switches

https://stackoverflow.com/questions/25744120/g-linking-static-and-non-static-libraries-at-the-same-time

For the Antipism installer on Windows, it makes sense for the programs
to link dynamically to the Antiprism library, as there are so many
of them, and so all the linking is dynamic, and I have also have to
distribute some compiler related DLLs, which change with compiler
versions...

If you build with 'g++ -static' then it may be that you do not have
to distribute anything but the program binary.

> If this is possible I'd like to know how to do it both in the linux build and
> the cross compiled programs. I cross compile in the cygwin environment but
> might it be possible to cross compile in ubuntu for the windows executables?

I create the Antiprism installer for Windows entirely on Ubuntu.
Everything in it is cross-compiled using MinGW, like it would be on
Cygwin. However, because Antiprism uses an Autotools build the
cross-compilation is managed by configure, e.g.

./configure --host x86_64-w64-mingw32

[Roger Kaufman]

Hi Adrian,

I'll have a look at the compilation suggestions. I've not done any
research on it yet.

Just a few notes.

On 5/27/2023 2:17 AM, Adrian Rossiter wrote:
> If the user wants to see the symmetry of the combined model then this
> can be done with off_util. The same situation exists with element
> number labels.

I thinks its nice that Antiview can do multiple models and off_util
would combine them. But in the case of doing the sub-symmetry trick, it
won't work if the separate geometries have incompatible symmetries.
However, it would be possible to do it at full symmetry and perhaps I
could make that an option.

So you think showing sub-symmetry visually makes it a worthy utility?
Having the extended helps shows the internal "sym_xx" model format. You
have examples of them on line but it is at the bottom of the page and I
wonder how many know about these. Its a unique idea.

>> Extended helps are borrowed from off_util -H help
>>
>> -H        Symmetry help and Symmetry Model help (from off_util -H help)
>>
>> A symmetry listing that includes free rotations and free
>> translations. In off_trans -y will say for what sub-symmetries they
>> aren't allowed, but there is no reference for the ones that allow it.
>> But I noticed they are listed for compounds in the poly_kscope
>> program so I linked them similarly.
>
> Err, yes. They don't seem to be listed in the documentation anywhere!
> I'll
> review that. Maybe I'll make a symmetry documentation page based on the
> website symmetry topic page (which also doesn't list them, but does give
> an example that uses a free translation).

Maybe that listing format could go into off_util in place of
[symmetry_subgroups_nonconjugate]? It seems more useful. I just took the
off_report code and added to it so it could probably just be moved in.

The help for off_trans or poly_kscope helps don't have any examples that
use off_trans -Y (capital) and I'm not sure how to use it. There might
have been an example in the archive but searching on parameters doesn't
work very well. Does it allow alignment for subgroups that the model
doesn't have?

Roger

[Adrian Rossiter]

Hi Roger

On Sat, 27 May 2023, Roger Kaufman wrote:
> On 5/27/2023 2:17 AM, Adrian Rossiter wrote:
>> If the user wants to see the symmetry of the combined model then this
>> can be done with off_util. The same situation exists with element
>> number labels.
>
> I thinks its nice that Antiview can do multiple models and off_util would
> combine them. But in the case of doing the sub-symmetry trick, it won't work
> if the separate geometries have incompatible symmetries. However, it would be
> possible to do it at full symmetry and perhaps I could make that an option.
>
> So you think showing sub-symmetry visually makes it a worthy utility? Having
> the extended helps shows the internal "sym_xx" model format. You have
> examples of them on line but it is at the bottom of the page and I wonder how
> many know about these. Its a unique idea.

If the feature seems like it would be used, then it could be an extra
argument to antiview/off2* -s (with appropriate error handling), which
would not require much code.

A display of a subsymmetry relative to a fixed model can currently be
achieved in the same way as your approach, e.g.

off_color sym_D3v -f invisible -e invisible -v invisible | off_trans -Y cube,D3v -S 0.3 | off_util - cube | antiview -s a

>>> A symmetry listing that includes free rotations and free translations. In
>>> off_trans -y will say for what sub-symmetries they aren't allowed, but
>>> there is no reference for the ones that allow it. But I noticed they are
>>> listed for compounds in the poly_kscope program so I linked them
>>> similarly.
>>
>> Err, yes. They don't seem to be listed in the documentation anywhere! I'll
>> review that. Maybe I'll make a symmetry documentation page based on the
>> website symmetry topic page (which also doesn't list them, but does give
>> an example that uses a free translation).
>
> Maybe that listing format could go into off_util in place of
> [symmetry_subgroups_nonconjugate]? It seems more useful. I just took the
> off_report code and added to it so it could probably just be moved in.

The permitted realignments belong only to the group, and so these could
be listed in the Schoenflies notation section of 'off_util -H symmetry'.

I guess something like 'off_trans -y C6v,list' could list the number
of non-conjugate subgroups and the free variables for realignment,
which could be useful for making clear all the possibilities.

> The help for off_trans or poly_kscope helps don't have any examples that use
> off_trans -Y (capital) and I'm not sure how to use it. There might have been
> an example in the archive but searching on parameters doesn't work very well.
> Does it allow alignment for subgroups that the model doesn't have?

I'll add something to the program documentation. There are examples in the
topic album

https://www.antiprism.com/examples/250_topics/100_symmetry/imagelist.html

The idea of -y and -Y is to break a symmetry alignment transformation
down into two steps: -y adds a transformation that aligns a subsymmetry of
the base model with the Antiprism standard alignment for the group, and -Y
adds a transformation that aligns an Antiprism standard symmetry group
alignment with a subsymmetry of another model or another symmetry group.

In which case, to align a base model with a fixed model so they share a
symmetry subgroup, align the base model symmetry subgroup with the standard
group using -y, then align the standard group with its alignment in the
fixed model using -Y.

If a model doesn't have the symmetry subgroup that is specified in -y
or -Y, then it cannot be used for alignment, and so this is an error.

[Roger Kaufman]

Hi Adrian,

On 5/27/2023 2:17 AM, Adrian Rossiter wrote:

Link statically to create standalone programs? I was wondering if this was still possible. I have programs I wrote for Hedron that I haven't maintained because I can no longer distribute the standalone executables. Here is my makefile that refers to my base directory

As I recall, the main issue is that it can be difficult to build
a binary that depends on both static and dynamic libraries. I think
I sometimes specify the static library as an object file during linking,
and I believe it can also be done with options that act like switches

   https://stackoverflow.com/questions/25744120/g-linking-static-and-non-static-libraries-at-the-same-time

For the Antipism installer on Windows, it makes sense for the programs
to link dynamically to the Antiprism library, as there are so many
of them, and so all the linking is dynamic, and I have also have to
distribute some compiler related DLLs, which change with compiler
versions...

If you build with 'g++ -static' then it may be that you do not have
to distribute anything but the program binary.

Now that vrml has become of interest again (at least for me), I am going to restore vrml 1 to vrml 2 project page, that I just took down a few weeks ago. Interestingly, someone had taken all those programs and put them in git (minus the source code), around 11 years ago.

I have the source code (from 2007!) of the vr1tovr2 wrapper for the old SGI binary and I wanted to update it. This got me back to having to make a static executable.

This turns out to be possible. With the following compiler setup. Found here:

https://stackoverflow.com/questions/13768515/how-to-do-static-linking-of-libwinpthread-1-dll-in-mingw

LDFLAGS="-L/usr/x86_64-pc-cygwin/sys-root/usr/lib" \
CXX="x86_64-w64-mingw32-g++ -Wall -Wextra -static -static-libgcc -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread" \
./configure --host=x86_64-w64-mingw32

This works except for compiling antiview. The executable go from ~60,000 to ~60,000,000 in size, a one hundred fold increase.

off_util.exe will for example run at a dos command prompt with no path or library dependencies and have all the builtin polyhedra working.

One thing I found doing it this way is the base/off_write.cc and src/col_util both have col_cmp class and cmp_col functions. Normally this doesn't matter. I can just rename them in col_util, or we can try to make them public in /base.

This make the distribution of standalone executable's again.

Roger

[Adrian Rossiter]

Hi Roger

On Tue, 25 Jul 2023, Roger Kaufman wrote:
> This works except for compiling antiview. The executable go from ~60,000 to
> ~60,000,000 in size, a one hundred fold increase.

For antiview, you can probably build it against a static glut library.

You may be able to reduce executable sizes considerably with 'strip'.

> One thing I found doing it this way is the base/off_write.cc and src/col_util
> both have col_cmp class and cmp_col functions. Normally this doesn't matter.
> I can just rename them in col_util, or we can try to make them public in
> /base.

Symbols in library .cc source files that should not be exported, like
local helper functions, can be kept local by wrapping them in an
unnamed namespace (with an effect like when a function is declared
'static').

namespace {
// code declaring symbols that should not be exported
...
};


If you wrap cmp_col and col_cmp like this in base/off_write.cc then
col_util should link against the static library (and you could push
the changes).

[Roger Kaufman]

Hi Adrian,

Preface... I've begun doing all compiling in Ubuntu and will probably
retire any compilations in Cygwin. Cygwin is now only my working
environment in Windows.

The windows cross compilation so far looks like this

CXX="x86_64-w64-mingw32-g++ -Wall -Wextra -static -static-libgcc
-static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread" \
./configure --host=x86_64-w64-mingw32

On 7/28/2023 10:17 AM, Adrian Rossiter wrote:
> On Tue, 25 Jul 2023, Roger Kaufman wrote:
>> This works except for compiling antiview. The executable go from
>> ~60,000 to ~60,000,000 in size, a one hundred fold increase.
>
> For antiview, you can probably build it against a static glut library.

I haven't been able antiview to compile. I get this part of configure
saying it won't build. I have tried things like adding -lglu32 and
-lopengl32 etc to CXX but that doesn't help.

I know in Cygwin it will partially compile but won't link and that
freeglut is said to be unmaintained. (many packages say unmaintained now
and it is probably not a good development environment anymore).

checking for GL/gl.h... yes
checking for OpenGL/gl.h... no
checking for OpenGL library... -lopengl32
checking for GL/glu.h... yes
checking for OpenGL/glu.h... no
checking for OpenGL Utility library... -lglu32
checking for varargs GLU tesselator callback function type... no
checking for XmuScreenOfWindow in -lXmu... no
checking for XIQueryVersion in -lXi... no
checking for GL/glut.h... no
checking for GLUT/glut.h... no
checking for GLUT library... no
*********************************************
   missing GLUT library or header
   check GLUT development package is installed
*********************************************
*********************************************
   antiview will not be built
   missing OpenGL or GLUT components (details above)
*********************************************

---------------------

Without anything static I was getting this....

checking for OpenGL/gl.h... no
checking for OpenGL library... -lGL
checking for GL/glu.h... yes
checking for OpenGL/glu.h... no
checking for OpenGL Utility library... -lGLU
checking for varargs GLU tesselator callback function type... no
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for XmuScreenOfWindow in -lXmu... no
checking for XIQueryVersion in -lXi... no
checking for GL/glut.h... yes
checking for GLUT/glut.h... no
checking for GLUT library... -lglut
OpenGL/GLUT found, antiview will be built

>
> You may be able to reduce executable sizes considerably with 'strip'.

I forgot about this! It is built into install-strip so it is automatic then.

>> One thing I found doing it this way is the base/off_write.cc and
>> src/col_util both have col_cmp class and cmp_col functions. Normally
>> this doesn't matter. I can just rename them in col_util, or we can
>> try to make them public in /base.
>
> Symbols in library .cc source files that should not be exported, like
> local helper functions, can be kept local by wrapping them in an
> unnamed namespace (with an effect like when a function is declared
> 'static').
>
> namespace {
>    // code declaring symbols that should not be exported
>    ...
> };
>
>
> If you wrap cmp_col and col_cmp like this in base/off_write.cc then
> col_util should link against the static library (and you could push
> the changes).

I pushed the change to off_write.cc

Roger

[Adrian Rossiter]

Hi Roger

On Tue, 1 Aug 2023, Roger Kaufman wrote:
> CXX="x86_64-w64-mingw32-g++ -Wall -Wextra -static -static-libgcc
> -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread" \
> ./configure --host=x86_64-w64-mingw32

...
> checking for GL/glut.h... no
...

> Without anything static I was getting this....

...
> checking for GL/glut.h... yes

You could check config.log for the difference between the success and
the failure. It looks like the test might be doing something more than
just checking for the existence of the header (perhaps also linking with
a static library that doesn't exist?).

It might be an idea to build a static Freeglut library and install it
into its own directory, and then build against that using --with-freeglut
and specifying the library location with -I in CPPFLAGS and -L in LDFLAGS.

[Roger Kaufman]

Hi Adrian,

On 8/3/2023 2:32 AM, Adrian Rossiter wrote:
> You could check config.log for the difference between the success and
> the failure. It looks like the test might be doing something more than
> just checking for the existence of the header (perhaps also linking with
> a static library that doesn't exist?).

Something must be missing from my Ubuntu packages. I found it won't
attempt antiview even without -static with a plain compile.

CXX="x86_64-w64-mingw32-g++ -Wall -Wextra" \
./configure --host=x86_64-w64-mingw32

The package I used was g++-mingw-w64-x86-64-posix because it addresses
libwinpthreads which is does and is noted here

https://stackoverflow.com/questions/17242516/mingw-w64-threads-posix-vs-win32

You must have something I don't or did you compile freeglut?

Roger

[Adrian Rossiter]

Hi Roger

On Thu, 3 Aug 2023, Roger Kaufman wrote:
> You must have something I don't or did you compile freeglut?

I cross-compiled Freeglut to use for the Antiprism Windows installer. The
build includes a static Freeglut library, but I link dynamically for the
installer.

[Roger Kaufman]

Hi Adrian,

I had accomplished what I wanted with a static build of addons for
antiprism. I thought while I was at it, I'd free myself of compiling in
Cygwin.

Partial success :)

Now I get to the point where antiview won't link properly. But at least
I'm to the same point as I am in Cygwin and no longer have to maintain a
build there.

If we can't get any further than this then I'm none the worse. All
Antiprism programs run without any library requirements with the static
build. Only antiview will require the libraries.

How it progressed...

On 8/3/2023 1:58 PM, Adrian Rossiter wrote:
> I cross-compiled Freeglut to use for the Antiprism Windows installer. The
> build includes a static Freeglut library, but I link dynamically for the
> installer.
>

configure requires finding glut.h under the GL directory. What I have is
this.

roger@interocitor-ubuntu:/usr/x86_64-w64-mingw32$ find . -name gl*

./include/GL/glaux.h
./include/GL/glext.h
./include/GL/glxext.h
./include/GL/glu.h
./include/GL/gl.h
./include/GL/glcorearb.h

This seems odd that glut.h isn't there. What is in Cygwin are some extra
files. They are dated 2013 and it makes me think they are there from
when I used to build and install freeglut.

Roger@interocitor:/usr/x86_64-w64-mingw32/sys-root/mingw/include/GL$ ls -l
total 1490
-rw-r--r-- 1 Roger Administrators    681 Dec  1  2013 freeglut.h
-rw-r--r-- 1 Roger Administrators   9007 Dec  1  2013 freeglut_ext.h
-rw-r--r-- 1 Roger Administrators  26523 Dec  1  2013 freeglut_std.h
-rw-r--r-- 1 Roger Administrators  45301 Apr 29 05:57 gl.h
-rw-r--r-- 1 Roger Administrators   6858 Apr 29 05:57 glaux.h
-rw-r--r-- 1 Roger Administrators 419260 Apr 29 05:57 glcorearb.h
-rw-r--r-- 1 Roger Administrators 841944 Apr 29 05:57 glext.h
-rw-r--r-- 1 Roger Administrators  10310 Apr 29 05:57 glu.h
-rw-r--r-- 1 Roger Administrators    639 Dec  1  2013 glut.h
-rw-r--r-- 1 Roger Administrators  48370 Apr 29 05:57 glxext.h
-rw-r--r-- 1 Roger Administrators  50304 Apr 29 05:57 wgl.h
-rw-r--r-- 1 Roger Administrators  43782 Apr 29 05:57 wglext.h

These files are on
https://github.com/FreeGLUTProject/freeglut/tree/master/include/GL

I added these in the directory but there is no library. On Cygwin there
is this again from 2013.

 Roger@interocitor:/usr/x86_64-w64-mingw32/sys-root/mingw/lib$ ls -l
libglut*
-rw-r--r-- 1 Roger Administrators 392220 Dec  1  2013 libglut.a
-rwxr-xr-x 1 Roger Administrators  96460 Dec  1  2013 libglut.dll.a

Other libraries are the same size in bytes as they are on Cygwin. Could
these actually be transferable?

They are (this is surprising!)

Results of linking antiview...

/bin/bash ../libtool  --tag=CXX   --mode=link x86_64-w64-mingw32-g++

-Wall -Wextra -static -static-libgcc -static-libstdc++ -Wl,-Bstatic

-lstdc++ -lpthread  -lm    -o libantiprism_dispgl.la  gl_writer.lo
stipple.lo gl_stroke_font.lo displaypoly_gl.lo  -lglu32 -lopengl32 -lm
libtool: link: x86_64-w64-mingw32-ar cr .libs/libantiprism_dispgl.a
gl_writer.o stipple.o gl_stroke_font.o displaypoly_gl.o
libtool: link: x86_64-w64-mingw32-ranlib .libs/libantiprism_dispgl.a
libtool: link: ( cd ".libs" && rm -f "libantiprism_dispgl.la" && ln -s
"../libantiprism_dispgl.la" "libantiprism_dispgl.la" )
/bin/bash ../libtool  --tag=CXX   --mode=link x86_64-w64-mingw32-g++

-Wall -Wextra -static -static-libgcc -static-libstdc++ -Wl,-Bstatic

-lstdc++ -lpthread   -lm    -o antiview.exe antiview-antiview.o
antiview-vw_glut.o -lglut libantiprism_dispgl.la ../base/libantiprism.la
-lglu32 -lopengl32  -lm
libtool: link: x86_64-w64-mingw32-g++ -Wall -Wextra -static-libgcc
-static-libstdc++ -Wl,-Bstatic -o antiview.exe antiview-antiview.o
antiview-vw_glut.o  -lstdc++ -lpthread -lglut
./.libs/libantiprism_dispgl.a ../base/.libs/libantiprism.a -lglu32
-lopengl32
/usr/bin/x86_64-w64-mingw32-ld:
antiview-antiview.o:antiview.cc:(.text+0x68): undefined reference to
`__imp___glutInitWithExit'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-antiview.o:antiview.cc:(.text+0x8f): undefined reference to
`__imp___glutCreateWindowWithExit'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-antiview.o:antiview.cc:(.text+0xb5): undefined reference to
`__imp___glutCreateMenuWithExit'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-antiview.o:antiview.cc:(.text+0x5e4): undefined reference to
`__imp_glutInitDisplayMode'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-antiview.o:antiview.cc:(.text+0x605): undefined reference to
`__imp_glutInitWindowSize'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-antiview.o:antiview.cc:(.text+0x618): undefined reference to
`__imp_glutInitWindowPosition'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-antiview.o:antiview.cc:(.text+0x634): undefined reference to
`__imp_glutDisplayFunc'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-antiview.o:antiview.cc:(.text+0x644): undefined reference to
`__imp_glutIdleFunc'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-antiview.o:antiview.cc:(.text+0x654): undefined reference to
`__imp_glutReshapeFunc'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-antiview.o:antiview.cc:(.text+0x664): undefined reference to
`__imp_glutMouseFunc'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-antiview.o:antiview.cc:(.text+0x674): undefined reference to
`__imp_glutKeyboardFunc'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-antiview.o:antiview.cc:(.text+0x684): undefined reference to
`__imp_glutSpecialFunc'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-antiview.o:antiview.cc:(.text+0x694): undefined reference to
`__imp_glutMotionFunc'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-antiview.o:antiview.cc:(.text+0x7b9): undefined reference to
`__imp_glutMainLoop'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0x25): undefined reference to
`__imp___glutInitWithExit'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0x4c): undefined reference to
`__imp___glutCreateWindowWithExit'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0x72): undefined reference to
`__imp___glutCreateMenuWithExit'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0xa8): undefined reference to
`__imp_glutAddMenuEntry'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0xbd): undefined reference to
`__imp_glutAddMenuEntry'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0xd2): undefined reference to
`__imp_glutAddMenuEntry'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0xe7): undefined reference to
`__imp_glutAddMenuEntry'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0xfc): undefined reference to
`__imp_glutAddMenuEntry'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0x111): more undefined references
to `__imp_glutAddMenuEntry' follow
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0x204): undefined reference to
`__imp_glutAddSubMenu'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0x219): undefined reference to
`__imp_glutAddMenuEntry'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0x22e): undefined reference to
`__imp_glutAddMenuEntry'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0x23c): undefined reference to
`__imp_glutAttachMenu'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0x105c): undefined reference to
`__imp_glutPostRedisplay'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0x180f): undefined reference to
`__imp_glutPostRedisplay'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0x18ef): undefined reference to
`__imp_glutPostRedisplay'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0x19ba): undefined reference to
`__imp_glutSwapBuffers'
/usr/bin/x86_64-w64-mingw32-ld:
antiview-vw_glut.o:vw_glut.cc:(.text+0x1be1): undefined reference to
`__imp_glutPostRedisplay'
collect2: error: ld returned 1 exit status

Roger

[Roger Kaufman]

Hi Adrian,

On 8/3/2023 5:15 PM, Roger Kaufman wrote:
> I added these in the directory but there is no library. On Cygwin
> there is this again from 2013.
>
>  Roger@interocitor:/usr/x86_64-w64-mingw32/sys-root/mingw/lib$ ls -l
> libglut*
> -rw-r--r-- 1 Roger Administrators 392220 Dec  1  2013 libglut.a
> -rwxr-xr-x 1 Roger Administrators  96460 Dec  1  2013 libglut.dll.a
>
> Other libraries are the same size in bytes as they are on Cygwin.
> Could these actually be transferable?
>
> They are (this is surprising!)
>

Looking back in my emails I think the linkage problem existed back in
2013 as well and is probably just a fact.

Both platforms have the freeglut 2.8.1 package installed and that is
probably why I got away with the binary file transfers as I did. That
version was released in April 2013 and my installation files were from
December 2013.

Freeglut is up to version 3.4 and I could try to make a static build of
it but I would predict there would be incompatibilities in the antiview
code. Another downside is that, if that were to become the dependency,
anyone who built Antiprism would then require building freeglut instead
of installing the package.

Roger

[Roger Kaufman]

Hi Adrian,

On 8/3/2023 5:15 PM, Roger Kaufman wrote:

> libtool: link: x86_64-w64-mingw32-g++ -Wall -Wextra -static-libgcc
> -static-libstdc++ -Wl,-Bstatic -o antiview.exe antiview-antiview.o
> antiview-vw_glut.o  -lstdc++ -lpthread -lglut
> ./.libs/libantiprism_dispgl.a ../base/.libs/libantiprism.a -lglu32
> -lopengl32
> /usr/bin/x86_64-w64-mingw32-ld:
> antiview-antiview.o:antiview.cc:(.text+0x68): undefined reference to
> `__imp___glutInitWithExit'

By added -lglut.dll (which is the file libglut.dll.a from the 2013
static build), it will link.

CXX="x86_64-w64-mingw32-g++ -Wall -Wextra -static -static-libgcc
-static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread -lglut.dll" \
./configure --host=x86_64-w64-mingw32

The only library still needed is libglut-0.dll. In a directory on a
laptop without antiprism or cygwin, this will run antiview (I renamed it
temporarily to avoid the possibility of running another antiview if it
were in a path).

08/04/2023  12:39 PM         3,247,104 aview.exe
12/01/2013  06:01 PM           226,816 libglut-0.dll

Such as this, aview geo_3 will display the model.

When I look up information on libglut-0.dll, I find a lot of sites
offering the file for download.

There is a hint I've seen to get it compiled into the binary. I tried
this and it links without error, but the binary is the same size and
still has the dependency so this isn't doing anything.

x86_64-w64-mingw32-g++ -Wall -Wextra -static-libgcc -static-libstdc++

-Wl,-Bstatic -o antiview.exe /usr/x86_64-w64-mingw32/lib/libglut-0.dll

antiview-antiview.o antiview-vw_glut.o -lstdc++ -lpthread -lglut

./.libs/libantiprism_dispgl.a -lglut.dll ../base/.libs/libantiprism.a
-lglu32 -lopengl32

Roger

[Adrian Rossiter]

Hi Roger

On Fri, 4 Aug 2023, Roger Kaufman wrote:
> Freeglut is up to version 3.4 and I could try to make a static build of it
> but I would predict there would be incompatibilities in the antiview code.
> Another downside is that, if that were to become the dependency, anyone who
> built Antiprism would then require building freeglut instead of installing
> the package.

There are at least two errors in the build which potentially affect this,
but fixing them still leaves unresolved symbols from the the freeglut
library. These symbols don´t exist in the freeglut library, but I think
they are supposed to be resolved by symbols in the library with the same
name but without '_imp__'.

There is also a potential issue that the opengl library is probably a
DLL, but static linking has been specified, and it may be necessary to
switch back to shared linking for this library.

I'll try to review this some more.

[Roger Kaufman]

Hi Adrian,

On 8/4/2023 2:28 PM, Adrian Rossiter wrote:
> There is also a potential issue that the opengl library is probably a
> DLL, but static linking has been specified, and it may be necessary to
> switch back to shared linking for this library.

Here are the files I had on Cygwin that I used in Ubuntu. I placed them
out amongst the system files but I probably will end up keeping them in
a local directory.

It wouldn't let me attach it but here it is as a link.

https://www.interocitors.com/tmp/glut_include.zip

Roger

[Adrian Rossiter]

Hi Roger

On Fri, 4 Aug 2023, Adrian Rossiter wrote:
> There are at least two errors in the build which potentially affect this,
> but fixing them still leaves unresolved symbols from the the freeglut
> library. These symbols don´t exist in the freeglut library, but I think
> they are supposed to be resolved by symbols in the library with the same
> name but without '_imp__'.

I have pushed two changes to the build, relating to antiview. It should
now respect CXXFLAGS, and also ensure the library link order is correct.

It doesn't fix the issue with undefined glut symbols.

Here is a link which talks about _imp__ symols

https://stackoverflow.com/questions/22766540/semantics-of-imp-symbols

They seem to relate to DLLs...

[Adrian Rossiter]

Hi Roger

On Sat, 5 Aug 2023, Adrian Rossiter wrote:
> It doesn't fix the issue with undefined glut symbols.
>
> Here is a link which talks about _imp__ symols
>
> https://stackoverflow.com/questions/22766540/semantics-of-imp-symbols

Here is another link, that describes the exact sitution with the
undefined symbols when linking to glut statically, and suggests
where to look for getting the build configured correctly

https://stackoverflow.com/questions/52204835/static-library-missing-imp-symbols

[Roger Kaufman]

Hi Adrian,

On 8/4/2023 1:08 PM, Roger Kaufman wrote:
> By added -lglut.dll (which is the file libglut.dll.a from the 2013
> static build), it will link.
>
> CXX="x86_64-w64-mingw32-g++ -Wall -Wextra -static -static-libgcc
> -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread -lglut.dll" \
> ./configure --host=x86_64-w64-mingw32

I should have noted this links with out the _imp problem.

I was looking for the origin libglut.dll.a

I found a hint here

https://stackoverflow.com/questions/62934726/where-is-freeglut-a-in-cygwin

so putting in the command in cygwin bash

 cygcheck -p libglut.dll.a
Found 5 matches for libglut.dll.a
libglut-devel-3.0.0-1 - libglut-devel: OpenGL Utility Toolkit library
libglut-devel-3.2.1-1 - libglut-devel: OpenGL Utility Toolkit library
libglut-devel-3.4.0-1 - libglut-devel: OpenGL Utility Toolkit library
mingw64-i686-freeglut-2.8.1-1 - mingw64-i686-freeglut: Open Source GLUT
implementation for Win32 toolchain
mingw64-x86_64-freeglut-2.8.1-1 - mingw64-x86_64-freeglut: Open Source
GLUT implementation for Win64 toolchain

I have both of these packages in cygwin and it indicates the library may
not have been built, but supplied.

These are packages cygwin centric. The fact that it can work in the
cross compile on ubuntu is because it is a windows binary.

Roger

[Adrian Rossiter]

Hi Roger

On Sat, 5 Aug 2023, Roger Kaufman wrote:
> On 8/4/2023 1:08 PM, Roger Kaufman wrote:
>> By added -lglut.dll (which is the file libglut.dll.a from the 2013 static
>> build), it will link.
>>
>> CXX="x86_64-w64-mingw32-g++ -Wall -Wextra -static -static-libgcc
>> -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread -lglut.dll" \
>> ./configure --host=x86_64-w64-mingw32
>
> I should have noted this links with out the _imp problem.
>
> I was looking for the origin libglut.dll.a

Is this a shared link that requires a runtime DLL?

I believe the shared link with the freeglut development library
that I built for windows links with libfreeglut.dll.a, and then
requires freeglut.dll to run.

I tried a static build against libfreeglut_static.a, which I renamed
to libfreeglut.a, with the macros

-D_WIN32 -DFREEGLUT_STATIC

This got rid of all the undefined imp symbols in Antiprism code, but I
ended up with some undefined symbols in the freeglut static library
instead, e.g.

/usr/bin/x86_64-w64-mingw32-ld: /home/adrian/proj/win_ant_inst/winglut64/libfreeglut.a(fg_init_mswin.c.obj):fg_init_mswin.:(.text+0x1d1): undefined reference to `__imp_GetDeviceCaps'

I was able to clear all these by aditionally linking with

-lgdi32 -lwinmm

I copied the resulting antiview binary over to Windows, and it ran fine.

I hardcoded the libraries into the build, as I wasn't to sure how to
configure it, but the macros can be added to CPPFLAGS. I will review
the build, so the extra libraries can be set in a variable.

[Roger Kaufman]

Hi Adrian,

On 8/5/2023 3:28 PM, Adrian Rossiter wrote:

I should have noted this links with out the _imp problem.

I was looking for the origin libglut.dll.a

Is this a shared link that requires a runtime DLL?

libglut.dll.a is a static glut library that has been distributed in some glut cygwin packages.

After it is linked in, using the static flags, the only library still needed at run time is libglut-0.dll which, in my cygwin setup, is in mingw/bin directory. I'm not sure of the source of libglut-0.dll but a search has found that it was in a freeglut 2.8.1 RPM file. I remember RPM files.

However, it isn't out of the question that these were generated doing a static build of freeglut 2.8.1. I haven't tried building freeglut for a long time but these both have the same time stamp of 12/3/2013 4:01 PM. Even then, there was some reason I went with FLTK.

In Cygwin and Ubuntu the freeglut installation pages stop at version 2.8.1 and, its just an assumption, that other packages are dependent on how 2.8.1 was set up. Or the author never promoted a newer version.

I'd like to take some of the guess work out of this! Are we still using version 2.8.1 as part of the Windows installation package?

I think we could provide instructions on how to do a static windows cross compile of Antiprism as part of the documentation. If it does require libglut-0.dll for antiview, then its not perfect, but at least stand alone distributable exe's are possible.

That being said, this is the point I am at now.

Roger

[Adrian Rossiter]

Hi Roger

On Sun, 6 Aug 2023, Roger Kaufman wrote:
> I'd like to take some of the guess work out of this! Are we still using
> version 2.8.1 as part of the Windows installation package?
>
> I think we could provide instructions on how to do a static windows cross
> compile of Antiprism as part of the documentation. If it does require
> libglut-0.dll for antiview, then its not perfect, but at least stand alone
> distributable exe's are possible.

I can't see the Freeglut version I used, but I built it in April, so
it is probably Freeglut 3.4.0.

The antiview binary I built didn't rely on a Freeglut DLL. I copied
the single binary to Windows and ran it from a DOS Box.

There are currently no cross-compilation instructions for Antiprism. If
you wanted to support a variety of GLUTs then the instructions might get
complicated and be difficult to mintain.

[Roger Kaufman]

Hi Adrian,

On 8/6/2023 3:54 PM, Adrian Rossiter wrote:
> I can't see the Freeglut version I used, but I built it in April, so
> it is probably Freeglut 3.4.0.
>
> The antiview binary I built didn't rely on a Freeglut DLL. I copied
> the single binary to Windows and ran it from a DOS Box.
>
> There are currently no cross-compilation instructions for Antiprism. If
> you wanted to support a variety of GLUTs then the instructions might get
> complicated and be difficult to mintain.

I don't want to mess up my build as it is working.

I still have a Ubuntu 20.04 build. There I will uninstall the
freeglut3-dev package (which says it version 2.8.1 so why 3?) and then
build/install Freeglut 3.4.0 and experiment. But note that in the README
we do say "freeglut3-dev". Also I just noticed about the --with-freeglut
option which I don't use and maybe I should have been?

As for building the rest of the programs statically, this command will
do that. I don't know if it could be shortened but this is the command
line found around the web.

CXX="x86_64-w64-mingw32-g++ -Wall -Wextra -static -static-libgcc

-static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread" \
./configure --host=x86_64-w64-mingw32

I was also thinking I could post statically built antiprism programs on
my google drive. However, I think this could lead to Antiprism programs
of previous version getting mixed up. I won't make this a high priority
or not at all if you think it is unwise. In which case even mentioning
it can be done in the documentation might also be unwise lol.

Roger

[Adrian Rossiter]

Hi Roger

On Sun, 6 Aug 2023, Roger Kaufman wrote:

> I still have a Ubuntu 20.04 build. There I will uninstall the freeglut3-dev
> package (which says it version 2.8.1 so why 3?) and then build/install
> Freeglut 3.4.0 and experiment. But note that in the README we do say
> "freeglut3-dev". Also I just noticed about the --with-freeglut option which I
> don't use and maybe I should have been?

Using --with-freeglut just means that components with 'freeglut' names are
used during the build.

I just checked the Ubuntu Freeglut package and it installs libraries
called libglut.a and libglut.so*, so using --with-freeglut won't work.
If you install Freeglut directly and want to use static linking then
you will need to ensure that the static library is called libfreeglut.a
if you are using this switch.

[Adrian Rossiter]

Hi Roger

On Sat, 5 Aug 2023, Adrian Rossiter wrote:
> I tried a static build against libfreeglut_static.a, which I renamed
> to libfreeglut.a, with the macros
>
> -D_WIN32 -DFREEGLUT_STATIC

...

> I was able to clear all these by aditionally linking with
>
> -lgdi32 -lwinmm

...

> I hardcoded the libraries into the build, as I wasn't to sure how to
> configure it, but the macros can be added to CPPFLAGS. I will review
> the build, so the extra libraries can be set in a variable.

I have pushed an update to the build.

When building for Windows the two extra libraries are automatically
linked.

If building static binaries then set CPPFLAGS as above if linking
against a cross-compiled Freeglut installed to a local directory.

I just tested cross-compiling for Windows with a static build, where
antiview.exe worked without any bundled DLLs, and with the Windows
installer build, which worked as usual.

I also checked the Ubutu shared link build, as a test of side-effects.