Linux-Development-Sys Digest #968, Volume #6     Fri, 16 Jul 99 15:14:08 EDT

Contents:
  Re: undefined reference to `crypt' (David T. Blake)
  Re: OLE in Linux? (M Sweger)
  Re: undefined reference to `crypt' (Scott Lanning)
  Re: undefined reference to `crypt' (Mark Tranchant)
  Re: NT to Linux port questions (Michel Bardiaux)
  Re: Makefiles for multiple programmers (mlw)
  Re: egcs idiocy (gene)
  Re: Makefiles for multiple programmers (John McDonald, Jr.)
  need insight on RH 6.0 executable loading problem (peter hatch)
  Re: Bug of GCC (Paul D. Smith)
  Re: has no current->timeout structure in kernel 2.2.X? (Kaz Kylheku)
  Re: mpeg-1 decode routine (Tristan Wibberley)
  Re: Bug of GCC (David T. Blake)
  Re: Makefiles for multiple programmers (David T. Blake)
  Re: NCR 53C710 Fast SCSI-2 Controller (Richard Bumby)

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

From: [EMAIL PROTECTED] (David T. Blake)
Crossposted-To: comp.unix.programmer
Subject: Re: undefined reference to `crypt'
Date: 16 Jul 1999 14:09:16 GMT
Reply-To: [EMAIL PROTECTED]

Robert <[EMAIL PROTECTED]> wrote:
>
>Result :
>/tmp/cca025131.o(.text+0x12c9): undefined reference to `crypt'
>
>What have missing ?
>
>yaps: yaps.C md5.h md5.c global.h
>       gcc -ggdb -o yaps ${DEFINES} yaps.C md5.c

yaps: yaps.C md5.h md5.c global.h
        gcc -ggdb -o yaps ${DEFINES} yaps.C md5.c -lcrypt
                                                  ^^^^^^^


-- 
Dave Blake
[EMAIL PROTECTED]

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

From: [EMAIL PROTECTED] (M Sweger)
Subject: Re: OLE in Linux?
Date: 16 Jul 1999 14:08:03 GMT
Reply-To: [EMAIL PROTECTED]

Peter Allen ([EMAIL PROTECTED]) wrote:
: Christopher Browne wrote:
: > 
: > On Thu, 15 Jul 1999 20:10:07 +0100, Peter Allen
: > <[EMAIL PROTECTED]> wrote:
: > >I thought that all gnome apps supported the com superset orbs, so any
: > >native gnome apps should have com features, therefore ole.
: > 
: > "COM Superset ORBs?"

: Woops, that was me thinking faster than I can type, so I put the COM
: first instead of second :-)

Search for OLE on http://www.freshmeat.net

Somebody just posted an OLE library there within the last two weeks.

        [EMAIL PROTECTED]


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

From: [EMAIL PROTECTED] (Scott Lanning)
Crossposted-To: comp.unix.programmer
Subject: Re: undefined reference to `crypt'
Date: 16 Jul 1999 14:44:00 GMT

Robert ([EMAIL PROTECTED]) wrote:
: /tmp/cca025131.o(.text+0x12c9): undefined reference to `crypt'
:
: What have missing ?

Generally it means you forgot to link against the library which
defines the reference.

On my system, 'man 3X crypt' says "cc .... -lcrypt". YMMV.

--
Scott Lanning: [EMAIL PROTECTED], http://physics.bu.edu/~slanning
"It showed a lady, with a fur cap on and a fur stole, sitting upright
and holding out to the spectator a huge fur muff into which the whole
of her forearm had vanished!" --From Franz Kafka's Metamorphosis

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

From: Mark Tranchant <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: undefined reference to `crypt'
Date: Fri, 16 Jul 1999 14:56:21 +0100
Reply-To: [EMAIL PROTECTED]

You need to add -lcrypt to the gcc line, and ensure libcrypt exists on
your system.

Mark.

Robert wrote:
> 
> 
> Result :
> /tmp/cca025131.o(.text+0x12c9): undefined reference to `crypt'
> 
> MakeFile Contain :
> 
> 
> yaps: yaps.C md5.h md5.c global.h
>         gcc -ggdb -o yaps ${DEFINES} yaps.C md5.c

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

From: Michel Bardiaux <[EMAIL PROTECTED]>
Subject: Re: NT to Linux port questions
Date: Fri, 16 Jul 1999 17:34:51 +0200

Matthew Carl Schumaker wrote:
> 
> Matthew Carl Schumaker
> UPAC Lights Administrative Chairperson
> [EMAIL PROTECTED]
> veni, vedi, velcro
> I came, I saw, I stuck around
[snip]
> THe MS WaitForMultipleEvents has the ability to be called so it doesn't
> return unless ALL handles become signaled SIMULTANEOUSLY select can't do
> this.  Not to mention using either select() or poll() heavily in program
> can have very adverse effects on the speed of the program, and btw
> select() and poll() are both blocking calls.
[snip]

That is simply wrong. Both select() and poll() can be made non-blocking,
blocking for at most a specific time, or blocking forever.

-- 
Michel Bardiaux
UsrConsult S.P.R.L.  Rue Margot, 37  B-1457 Nil St Vincent
Tel : +32 10 65.44.15  Fax : +32 10 65.44.10

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

From: mlw <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Makefiles for multiple programmers
Date: Fri, 16 Jul 1999 16:01:27 +0000

Randy Galliher wrote:
> 
> Is there an optimal makefile for a large software project involving
> several programmers.  It is desireable to have the baseline source in a
> separate directory with the objects stored in libraries.   This would
> allow each programmer to build and test their own version of the project.
> 
> I have been looking for a "how-to" or an example of a makefile that does
> this already, but have found none on the net.
> 
> ------------------  Posted via SearchLinux  ------------------
>                   http://www.searchlinux.com

The way I always do it is have the product organized in a hierarchical
directory structure. Each directory has its own Makefile. Each of the
Makefiles include a master Makefile that has all the prepackaged defines
and info. For instance:

/project/
        /inc
        /config
        /functlib.1
        /functlib.1/platform
        /functlib.2
        /functlib.2/platform
        /functlib.3
        /functlib.3/platform
        /lib
        /lib/platform
        /bin
        /bin/platform
        /apps
        /apps/platform

In all the sub makefiles, you would have:

include ../config/Makefile.mkf


That way, all the makefiles use standard defines managed separately. The
individual Makefiles are simple.

The "/platform" directories are repositories for platform specific files
like output objects.


                
-- 
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support. 
Visit http://www.mohawksoft.com

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

From: [EMAIL PROTECTED] (gene)
Subject: Re: egcs idiocy
Date: 16 Jul 1999 14:39:53 GMT

In article <z0rg3.12976$[EMAIL PROTECTED]>,
        "SV" <[EMAIL PROTECTED]> writes:
> just had
> a wonderfull experience
> compiling 2.2.8 kernel with
> gcc-2.7.2.3 and then
> with egcs-1.1.2.
> 
> Given everything else the same
> here are the sizes of kernel zimage
> compiled with gcc-2.7.2.3 and with egcs:
> 
> zimage by gcc-2.7.2.3        374314
> zimage by egcs-1.1.2         388066
> 
> one may ask why the hell one would want
> to use shitty compiler like egcs to bloat
> already bloated linux code?
> I had to, because I wanted to upgrade to
> glibc-2.1.1 which  is supposed to be
> compiled only with egcs or with gcc-2.8.x.
> Well, I did compile glibc-2.1.1 with egcs-1.1.2
> and guess what, the size of stripped libc-2.1.1.so
> came up more than 1M while the size of
> libc-2.0.6.so  compiled with gcc-2.7.2.3
> is a decent 600K. And this is given
> the number of global
> symbols in libc-2.0.6 appeared to be more then

Jeez, what a moron, doesn't even know how to spell or doesn't know the
between then and than.

> in libc-2.1.1.
> 
> On top of that I run a simple benchmark of a program
> compiled with egcs and with gcc-2.7.2.3 and the program
> compiled with egcs-1.1.2 ran in average 10-20% slower then

Jeez, what a moron, doesn't even know how to spell or doesn't know the
between then and than.

> the same exactly code compiled with gcc-2.7.2.3
> with the same exactly optimizations.
> 
> Someone already reported the latest and
> greatest linux kernel 2.3.9 runs 5-10% slower then

Jeez, what a moron, doesn't even know how to spell or doesn't know the
between then and than.

> kernel 2.2, which in turn, came out 200%-400% slower then
> Windows NT in PC Week benchmarks.
> 
> I feel like the whole linux is becoming just a heap
> of bugfixes piled up by a bunch of non-professional
> bafoons
> 
> Cordially,
> SV

Cordially,

-- 
::::: Gene Imes                      http://www.ozob.net :::::

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

From: [EMAIL PROTECTED] (John McDonald, Jr.)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Makefiles for multiple programmers
Date: Fri, 16 Jul 1999 16:27:54 GMT

On Fri, 16 Jul 1999 13:31:03 GMT, Randy Galliher
<[EMAIL PROTECTED]> wrote:

>Is there an optimal makefile for a large software project involving 
>several programmers.  It is desireable to have the baseline source in a 
>separate directory with the objects stored in libraries.   This would 
>allow each programmer to build and test their own version of the project.
>

This does not exactly answer your question, but have you tried Aegis?
Its a SCM tool to allow multiple programmers working off of the same
baseline.  Its supposedly a complete solution, although I have not
specifically worked with it yet.  I'm still learning how it works
before deploying it for my own applications.

[-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-]
 John K. McDonald, Jr.      Alcatel, USA

 [EMAIL PROTECTED]
 please remove -delete- for responses.
 --
 "I speak for me and not this company"

 TO SPAMMERS:
 Please  view   the  definitions   for 
 "telephone     facsimile    machine," 
 "unsolicted  advertisement,"  and the
 prohibition  and penalty  for sending
 unsolicited faxes before sending  Un-
 solicited  Commercial   E-mail to the 
 above   address.   Violators  WILL BE 
 PROSECUTED.   These   can   be  found
 in:
 
 The Telephone Consumer Protection Act
 of  1991,    Title   47,   Chapter 5,
 Subchapter II, Section 227.
[=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=]

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

From: peter hatch <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: need insight on RH 6.0 executable loading problem
Date: Fri, 16 Jul 1999 12:44:59 -0500

I've got an application (a Smalltalk IDE) that works perfectly fine
under glibc 2.0 (under RedHat 5.x).  When RedHat 6.0 (glibc 2.1) came
out, we started getting a very bizarr problem.

The application is compiled as a threaded executable, and does all of
it's own memory management.  There is a lot of signal handling as well. 
I've found that an executable compiled on a RH5.2 box has the exact same
problem as an executable compiled on a RH6.0 box....

At one point during the execution of the program (when the image is
starting up), there is a call to pthread_sighandler (which I guess is
new in glibc 2.1 linuxthreads).  The stack pointer before this call is
entered has a "bogus" value (falls within one of our own memory spaces)
and so the call writes the value of the signal (29-SIGIO) into this
memory space and causes an attribute of one of the objects in the system
to be dropped (causing a seg fault when that attribute is accessed).

So, after weeks of looking at this, I'm thuroghly flumoxed.  I found
that if I load the executable's data section at 0x80d49f5 or above
(instead of the default 0x80cd4e0 or "any" value below 0x80d49f5) the
application operates as intended.

I also found that the offending call to pthread_sighandler is always
activated during an Xlib call (while opening a display, in _Xread).

Does anyone have any ideas about this?  I'd welcome any input, no matter
how outlandish it seems :-)

TIA,
pete

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

From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Re: Bug of GCC
Date: 16 Jul 1999 12:09:01 -0400
Reply-To: [EMAIL PROTECTED]

%% [EMAIL PROTECTED] (Scott Lanning) writes:

  sl>     Anyway, I don't think the C standard has any business specifying
  sl> preprocessor behavior. But who cares what I think...? <sigh>

Apparently not anyone at all, at least in this respect ;).

A good portion of the standard is devoted to the preprocessor, and a
damn good thing it is, too.  The preprocessor is an _integral_ part of
the language!  That may not be true for some languages, but it's
unquestionably true of C.

How would you like to go back to the time where you couldn't rely on
things like:

  #if !defined(FOO) && !defined(BAR)

etc. because many compilers didn't support it?  There are also various
hacks that people used to use in place of token pasting (##) that
sometimes worked and sometimes didn't.  Etc. etc.  Maybe you're too
young to remember the Bad Old Days :).

Trust me, the standard has an absolute obligation to define the
preprocessor.

-- 
===============================================================================
 Paul D. Smith <[EMAIL PROTECTED]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
   These are my opinions---Nortel Networks takes no responsibility for them.

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

From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: has no current->timeout structure in kernel 2.2.X?
Date: Fri, 16 Jul 1999 16:32:49 GMT

On 16 Jul 1999 09:47:20 GMT, robert_c <[EMAIL PROTECTED]> wrote:
>Hi:
>    I have a problem in porting code from kernel 2.0.X to 2.2.X.
>In 2.0.X, I need a blocking function to do time deleayed and it was
>implemented like following .
>
>(Delay 3 second)
>  ...
>  ...
> int delay_second = 3;
> unsigned long total_jiffies = jiffies + delay_second *HZ;
>  ...
>
> current->timeout = total_jiffies; //<-- has no current->timeout data
>structure in kernel 2.2.X?
> current->state = TASK_INTERRUPTIBLE;
> schedule();
> current->timeout = 0;  // (reset the timeout) the error like above, <-- has
>no current->timeout data structure in kernel 2.2.X?

In kernel 2.2.X there is a function called schedule_timeout().

It works by registering a timer callback which wakes the process up. So
it doesn't need a timeout field in the process structure.

You can use that function to do timed out waits. Just call it in place of
schedule(). The argument is the delay value in jiffies.
  
You pass a delta value to schedule timeout, representing the delay in jiffies.
It returns the remaining jiffies if it woke up early, otherwise zero. (It's
probably best to assume that just because it returns zero doesn't mean that it
*wasn't* explicitly woken up).  The argument and return value are signed long,
so watch out.

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

From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: mpeg-1 decode routine
Date: Thu, 15 Jul 1999 16:07:03 +0100
Reply-To: [EMAIL PROTECTED]

Eelco Grakist wrote:
> 
> Hi y'all
> 
> does anybody know about a c-source (or api) to decode an mpeg1 stream?
> (like an AVI file)
> 
> I triend mptv-sdk, but this is an api to decode AND play the stream. But
> I don't need the play part, I just need the uncompressed frames.
> 
> I don't think I want to write a realtime mpeg1 decoder myself...

This isn't really a question for comp.os.development.system -
comp.compression would be more appropriate.

If I understand you correctly, you just want standard (ie, any operating
system) C source code which will let you rip frames from an MPEG-1
stream.

I think you should try www.mpeg.org They have a page called something
like MSSG. There is source code for an encoder/decoder for mpeg1/2
there.

Please try to use these resources more appropriately, a newsgroup is
really for when you have something to accomplish which you require human
interaction. You can find the answer to this with just the web - it only
took me about 45 seconds to find this.

-- 
Tristan Wibberley

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

From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: Bug of GCC
Date: 16 Jul 1999 16:36:11 GMT
Reply-To: [EMAIL PROTECTED]

Scott Lanning <[EMAIL PROTECTED]> wrote:
>..., however my argument is not about whether one
>should conform to standard C. I agree with that, in general.
>
>Okay, let me recapitulate...
>
>1) Cute Panda wondered why the GNU C preprocessor doesn't allow
>   you put an apostrophe inside an #if 0 .. #endif.

>2) The reply was based on the premise that, it is not allowed
>   by standard C.

>3) I argued with that premise, giving examples in which the
>   GNU C preprocessor doesn't conform to standard C.

>If an argument is based on false premises, then the argument
>is invalid. This is basic logic...

Nobody's perfect.  The argument still stands that it would be
even better if gcc adhered more closely to the standard, not LESS
CLOSELY as you are suggesting. 

Are you really suggesting gcc ought to adhere less closely to the
standard ??

-- 
Dave Blake
[EMAIL PROTECTED]
em - the editor of choice

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

From: [EMAIL PROTECTED] (David T. Blake)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Makefiles for multiple programmers
Date: 16 Jul 1999 16:41:18 GMT
Reply-To: [EMAIL PROTECTED]

Randy Galliher <[EMAIL PROTECTED]> wrote:
>Is there an optimal makefile for a large software project involving 
>several programmers.  It is desireable to have the baseline source in a 
>separate directory with the objects stored in libraries.   This would 
>allow each programmer to build and test their own version of the project.
>
>I have been looking for a "how-to" or an example of a makefile that does 
>this already, but have found none on the net.

Try cranking up emacs and browsing the info tree. I know
emacs is a bloated piece of crap, but it is the best info
browser I know of.

The GNU utilities like make and autoconf/aclocal are fully 
documented in the info trees.

Or use the command 'info GNU'
(works for me)
-- 
Dave Blake
[EMAIL PROTECTED]
em - the editor of choice

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

From: [EMAIL PROTECTED] (Richard Bumby)
Crossposted-To: comp.os.linux.hardware
Subject: Re: NCR 53C710 Fast SCSI-2 Controller
Date: 16 Jul 1999 14:19:47 -0400

"Mike Coakley" <[EMAIL PROTECTED]> writes:

>Johan,

>Thanks for the response. I have gone through expert mode and made sure that
>the 53c7,8xx.o module is the one loading. (Using ALT-F3 and ALT-F4 give you
>a wealth of information during installation.) Is there some generic SCSI
>module that I can try. (I think I have tried all of the available modules
>though.)

>What I would also like to know is if any know who or how I can find out who
>wrote this module and how to contact them. The author is the authoritative
>knowledge and I figure if he/she can't figure it out no one can.

>Mike



Linux is open source.  You have the source code for the kernel,
including the driver you are interested in.  Every system include
these sources to allow a customized kernel to be compiled.  The code
itself may not be useful unless you have more information about the
card than is usually provided to end-users, but there should also
be comments indicating the development history and identifying the
authors.
-- 
R. T. Bumby **  Rutgers Math || Amer. Math. Monthly Problems Editor 1992--1996
[EMAIL PROTECTED]       ||   
Telephone:    [USA] 732-445-0277 (full-time message line) FAX 732-445-5530

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


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and comp.os.linux.development.system) via:

    Internet: [EMAIL PROTECTED]

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-System Digest
******************************

Reply via email to