• Glenn M. Lewis (31/31) Sep 24 2004 Hi Walter!
• Benjamin Herr (3/7) Sep 24 2004 I second this, except static linking will not really help my 64bit
• Daniel Horn (9/53) Sep 25 2004 I know it'skind of off topic, but you guys seem fluent in this:
• Bastiaan Veelo (6/15) Sep 25 2004 Would the Linux Standard Base help?

Glenn M. Lewis <Glenn_member pathlink.com> writes:

Hi Walter!

If you are going to continue to deliver Linux executables for 'dmd' without the
ability for users to compile it themselves (which is fine with me... I have no
problem with that), I highly recommend that you provide them as completely
statically linked executables so that users can run them on any Linux system
without problems.

I write and deliver EDA tools that literally run on thousands of different Linux
and HPUX boxes, and I have learned over the years that in order to keep my tools
running, I need to make sure that they are statically linked.

Yes, it does increase the executable size (slightly... really not much at all,
believe it or not), but the small size difference is certainly worth the
benefit.

My typical object compile lines look like this:
g++ -O -DLINUX -ansi -static -c -o help.o help.cpp

and my typical link lines look like this:
g++ -O -DLINUX -ansi -static -o myprog main.o help.o -lGL -lX11 -lXext -lm

Finally, I 'strip' it.  The result looks like this:

% file myprog
myprog: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux
2.2.5, statically linked, stripped

% file myprog  (on a different system)
myprog: ELF 64-bit LSB executable, IA-64, version 1 (SYSV), for GNU/Linux 2.4.0,
statically linked, stripped

% ldd myprog
not a dynamic executable

If you could do this, I would very much appreciate it.
I *really* want to use D/Ruby/OpenGL for my next large-scale EDA tool, and
hopefully convince my entire department to switch over to D (and Ruby)... but if
we can't run 'dmd', it won't happen.

Thanks so much!!!
-- Glenn Lewis

Benjamin Herr <ben 0x539.de> writes:

Glenn M. Lewis wrote:
 If you could do this, I would very much appreciate it.
 I *really* want to use D/Ruby/OpenGL for my next large-scale EDA tool, and
 hopefully convince my entire department to switch over to D (and Ruby)... but
if
 we can't run 'dmd', it won't happen.

I second this, except static linking will not really help my 64bit 
problem. And except that I am not going to large-scale'ly use DMD.

Daniel Horn <hellcatv hotmail.com> writes:

I know it'skind of off topic, but you guys seem fluent in this:
hey--I ship a game that needs openGL (vegastrike.sf.net)...sure it's 
openSource but most of my users don't know how to compile...when I ship 
a binary it needs this or that glibc and is a mess (per distro sort of mess)
static not only destroys my linkage to the openGL driver of the week but 
also it segfaults upon launch...
any suggestions how to overcome this without requiring a version for 
each distro, and without statically linking in OpenGL?



Glenn M. Lewis wrote:
 Hi Walter!
 
 If you are going to continue to deliver Linux executables for 'dmd' without the
 ability for users to compile it themselves (which is fine with me... I have no
 problem with that), I highly recommend that you provide them as completely
 statically linked executables so that users can run them on any Linux system
 without problems.
 
 I write and deliver EDA tools that literally run on thousands of different
Linux
 and HPUX boxes, and I have learned over the years that in order to keep my
tools
 running, I need to make sure that they are statically linked.
 
 Yes, it does increase the executable size (slightly... really not much at all,
 believe it or not), but the small size difference is certainly worth the
 benefit.
 
 My typical object compile lines look like this:
 g++ -O -DLINUX -ansi -static -c -o help.o help.cpp
 
 and my typical link lines look like this:
 g++ -O -DLINUX -ansi -static -o myprog main.o help.o -lGL -lX11 -lXext -lm
 
 Finally, I 'strip' it.  The result looks like this:
 
 % file myprog
 myprog: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux
 2.2.5, statically linked, stripped
 
 % file myprog  (on a different system)
 myprog: ELF 64-bit LSB executable, IA-64, version 1 (SYSV), for GNU/Linux
2.4.0,
 statically linked, stripped
 
 % ldd myprog
 not a dynamic executable
 
 If you could do this, I would very much appreciate it.
 I *really* want to use D/Ruby/OpenGL for my next large-scale EDA tool, and
 hopefully convince my entire department to switch over to D (and Ruby)... but
if
 we can't run 'dmd', it won't happen.
 
 Thanks so much!!!
 -- Glenn Lewis
 
 

Bastiaan Veelo <Bastiaan.N.Veelo ntnu.no> writes:

Daniel Horn wrote:
 I know it'skind of off topic, but you guys seem fluent in this:
 hey--I ship a game that needs openGL (vegastrike.sf.net)...sure it's 
 openSource but most of my users don't know how to compile...when I ship 
 a binary it needs this or that glibc and is a mess (per distro sort of 
 mess)
 static not only destroys my linkage to the openGL driver of the week but 
 also it segfaults upon launch...
 any suggestions how to overcome this without requiring a version for 
 each distro, and without statically linking in OpenGL?

Would the Linux Standard Base help? 
http://refspecs.freestandards.org/lsb.shtml
OpenGL is in there too. I don't know how many distributions actually 
comply though.

Bastiaan.