Compiling your own programs

Compiling your own programs

Post by Yvan Lorang » Fri, 24 Aug 2001 06:06:07



I know [some if not all] reasons for compiling your own under Linux, but
I'm curious as to how many do-it-yourself people [percentage?] actually:

1) modify source code

2) read the source for suspicious code (*)

3) compile against a better environment than the software authors used

Any ideas or pointers to "studies"?

--
Merci........Yvan                    There's an old proverb
                      that says just about whatever you want it to say.

 
 
 

Compiling your own programs

Post by Michael Lee Yoh » Fri, 24 Aug 2001 10:16:52


Quote:> 1) modify source code

Quite often if I find something an author has neglected to think about,
I'll add it - make a diff patch, and re-submit it back to the author for
future distribution.

Quote:> 2) read the source for suspicious code (*)

Depends on the code - but an honest general response is "no".  However,
if something suspicious is happening with one of the services running on
the machine, then - yes, I'll attempt to find obvious problems with the
program.

Quote:> 3) compile against a better environment than the software authors used

Depends - if I have a faster performance library than what the author
used, then yes - I'll re-link it with my own library.
--


Software Developer, Engineering Services
Red Hat, Inc.

QUIPd 0.12:
-> I don't see much reason to reject the patch other than to be the
-> mud around a stick.
-> - Larry Wall

 
 
 

Compiling your own programs

Post by Dances With Cro » Fri, 24 Aug 2001 11:46:14


On 22 Aug 2001 21:06:07 GMT, Yvan Loranger staggered into the Black Sun
and said:

Quote:>I know [some if not all] reasons for compiling your own under Linux,
>but I'm curious as to how many do-it-yourself people [percentage?]
>actually:

>1) modify source code
>2) read the source for suspicious code (*)
>3) compile against a better environment than the software authors used

>Any ideas or pointers to "studies"?

(*):  Missing footnote -- segmentation fault.

I don't know of any formal studies that have been done on this.
However, I'd take a wild guess and say that Linux users fall broadly
into these groups:

0.  Users who use what came with the default install and never look at
an RPM.
1.  Users who use rpm/apt-get/pkgtool to install the junk they need
2.  Users who grab tarballs and ./configure && make && make install

I would have to guess that most current Linux users fall into group 2,
since there is a lot of good stuff that isn't available in RPM format.
Once you start compiling things, you quickly find that there are typos
within some code, mangled Makefiles, paths that need to be changed
because the original author made assumptions, etcetera.  From there,
it's not a big leap to modifying the source itself, even if it's
something trivial like "I wonder if I can modify joystick.c and make
ljohn recognize all the buttons on my joystick..."

Point 3 is probably too vague.  "better environment" is very
subjective--after all, some would consider a stripped-down LFS to be the
best environment, and just try building KDE2 successfully there....

Your results will be skewed depending on where you ask this question,
naturally.

--
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin /     That which does not kill us
http://www.brainbench.com     /      makes us stranger.
-----------------------------/       --Trevor Goodchild, "AEon Flux"

 
 
 

Compiling your own programs

Post by Swif » Fri, 24 Aug 2001 18:08:29



Quote:>  1) modify source code
>  2) read the source for suspicious code (*)
>  3) compile against a better environment than the software authors used

It depends (ofcourse). When software (recent version) is available in
RPM-format from a trusted source (distributions most of the time) then I use
the RPM-file.

If I want software that is available in RPM, but not a recent version, then I
download the src-RPM, alter the spec-file as appropriate, change the tarball
with the new one, hussle a bit with patches and changes until I can build a
working RPM (all happens on a dedicated installation). Then I use that RPM.

If software isn't available in RPM, I'll do the ./configure, nano Makefile,
make && make install, but also create a spec-file for RPM. I build (almost)
all of my systems with RPM for the ease of things (f.i. crash-recovery, fs
verifying, queries, ...).

If software should be run as root, or is from an untrusted source (a tool
that a low number of people use) then I scan the sourcecode (scan = print on
the screen, and then diagonally read it :) for rare things.

--
  SwifT
  |- LUG : http://www.lugwv.be
  |- PGP Key-# : 0xCDBA2FDB
  `- "Happy Linux-user :)"

 
 
 

Compiling your own programs

Post by aflinsc » Sun, 26 Aug 2001 02:28:07



> I know [some if not all] reasons for compiling your own under Linux, but
> I'm curious as to how many do-it-yourself people [percentage?] actually:

> 1) modify source code

Sometimes, yes, most often the answer is no. I will do it when I see a
personal need (waving the magic chicken for certian newsgroups thru
pan is an example).  If the change is something that I feel might be
useful to other users, I will do it also, and share with the original
author of the program.

Quote:

> 2) read the source for suspicious code (*)

In general no.

Quote:

> 3) compile against a better environment than the software authors used

Depends on what you mean by better. Usually the reason is to make up
for a different set of libraries that I may have on my system vs the
original authors. Quite often I might be a release ahead or behind in
some libs compared to what the author had on their system.

as for the tarball/source/binary rpm, I prefer to use source rpm's as
it allows me to do all of the above fairly easily. When I can't get a
source rpm, and don't have the inclination to build my own rpm spec, I
will usually compile from the tarball and install using a utility like
checkinstall

 
 
 

1. CC compiled .so does not work with g++ compiled main program

I am trying to develop a shared library (.so) on Solaris to extend a

program, but it will not load.

We have boiled down the problem to an incompatability between the g++

and CC compilers. The main program is a C++ program compiled with g++.

For certain reasons, I need to compile my shared library with CC though.

If I do compile the library with g++ (compile ".o"s using -g and -fPIC

options, and linking with -shared option) it works, but if change to

Sun's CC compiler and compiler (compile ".o"s with -g and -PIC, link

with -G option) the module can no longer load; that is, the main program

can not call any of the functions in the library.

Something that makes this problem a bit easier is that the functions in

the library that must be called by the main program are c functions that

in turn call c++ functions. This at least keeps me from having to deal

with the name mangling problems that I know are an incompatability

between the two compilers.

Does anyone have information on what I would need to do to get a c++

library compiled with CC to be loaded from a main program compiled with

g++?

Brian


2. INN and a list of newsgroups

3. compile C programs with UNIX system calls (= Unix Programs??)

4. Linux audio recorder and editor?

5. Own Your Own Power Company!

6. Keyboard does not wok with Compaq Proliant 400

7. a.out* - I can't run my own programs

8. Working Radeon in X-win 4.1.0

9. How to link a program with my own library file?

10. get acces to my scanner over SANE in my own C-program

11. Executing own program fails - command not found

12. I want to own my own server. Help!

13. Using the NIS passwords in my own program