public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
To: "Corinna Vinschen" <cygwin@cygwin.com>
Subject: RE: duplicate regexec/regcomp functions detected
Date: Thu, 27 Dec 2001 10:20:00 -0000	[thread overview]
Message-ID: <000401c18efb$18115890$0e6307d5@BRAMSCHE> (raw)
In-Reply-To: <20011214113619.J740@cygbert.vinschen.de>

[-- Attachment #1: Type: text/plain, Size: 3758 bytes --]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Corinna Vinschen
> Sent: Friday, December 14, 2001 11:36 AM
> To: cygwin
> Subject: Re: duplicate regexec/regcomp functions detected
>
>
> On Thu, Dec 13, 2001 at 09:18:39PM +0100, Ralf Habacker wrote:
> > Hi all,
> >
> > kde needs the regexp functions regexec and regcomp.
> >
> > The cygwin lib contains the System V8 function call style, while the pcre
> package (pcreposix)
> > provides another style (the system V style I guess). The problem is now, that both libs
> > supports the same names for regexec and regcomp but with different
> parameter/return types.
> > This results sometimes in execution failures if the libs are not in the right order like
> > shown in the following example.
> >
> > pcre regexp wanted
> >
> > $ gcc ... -lpcreposix -lcygwin   -> okay
> >
> > $ gcc ... -lpthreads|-lm|-lc -lpcreposix -lcygwin   -> failure: the functions in
> cygwin lib
> > are used
>
> But that order should never happen EXCEPT you're making the big
> mistake to give `-lm' or `-lc' on the command line explicitly.
> Since -lcygwin is appended automagically and libc.a and libm.a
> are the same library anyway, the answer is simply, "Don't do that."

This may be for -lm and -lc, but what about libpthread

Think about this link line:

gcc -o test -lpthread main.o [-lcygwin]

This will result in multiple defined symbols for WinMain (expected that main.o contains a
main function).
You can say don't do this, but what about bigger packages like qt. The qt configuring process
does only allow like the above link line.

anyway, saying don't do this is a way, but solving this problem is another.

A general possible solution for this, is not to make several links to cygwin, but to create
linkage libraries with only special symbols used for each cygwin derivated lib, like pthread.
The appended script does exactly this for libpthread. It extracts the pthread relating object
files from libcygwin.a and create a new archive libpthread.a. Using this technology removes
any ordering problems with pthread and other libs on the input line.

> > Especially in libtool related environment with many dependency libs like kde
> this causes much
> > trouble.
> >
> > Should it not be better, to remove the regexp support from cygwin into a seperate lib, so
> > that users has an easier possibility to choose which regexp style they want ?
>
> We didn't want that for compatibility reasons.  We often already
> discussed to trash the V8 implementation in favor of a POSIX
> implementation but that would break older applications which we're
> trying to avoid.

I understand, but what about to cast the function to another name (like _prefix or so) in the
headerfiles.
This would prevent some debugging sessions for people, who are not very confirm with this
issue.

Another solution may be the concept of creating extracted linking libraries desribed above.

> Btw., we have another POSIX regex library besides pcreposix: -lregex.
> It's somewhat smaller and it's also DLLized.  OpenSSH's configure.ac
> file has a special check to see if a regex lib exists and if the base
> regexp implementation in the std C lib is POSIX compliant.  We added
> that to the OpenSSH configury a few weeks ago to make Cygwin happy.

Thanks for this hint.

> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Developer                                mailto:cygwin@cygwin.com
> Red Hat, Inc.
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>
>

[-- Attachment #2: make_libpthread --]
[-- Type: application/octet-stream, Size: 747 bytes --]

#!/bin/sh
#
# create specific link library for libpthread to avoid some linkage problems like double defined WinMain
#
# for example in "gcc -o test -lpthread main.o" WinMain is double defined 
# 

LIB_CYGWIN=/lib/libcygwin.a 
LIB_PTHREAD=/lib/libpthread.a 

# awk script for extracing gawk related object files 
GAWK='
$1 ~ /^d00/ { file = $1; gsub(":","",file); }
$3 ~ /^_pthread/ { print file; }
'

# make backup of pthread link library 
cp -f $LIB_PTHREAD $LIB_PTHREAD.org
rm -f $LIB_PTHREAD 

# extract pthread related object files 
nm $LIB_CYGWIN | gawk "$GAWK" | xargs ar x $LIB_CYGWIN 

# create new link library for pthread
ar cru $LIB_PTHREAD *.o
ranlib $LIB_PTHREAD 

# remove temporay files 
rm -f *.o



[-- Attachment #3: Type: text/plain, Size: 214 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

  reply	other threads:[~2001-12-27 17:25 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-13 12:48 Ralf Habacker
2001-12-14  2:40 ` Corinna Vinschen
2001-12-27 10:20   ` Ralf Habacker [this message]
2001-12-27 10:21     ` Christopher Faylor
2001-12-28  5:21       ` Ralf Habacker
2001-12-28  5:22         ` Robert Collins
2001-12-28 10:17         ` Christopher Faylor
2001-12-29 12:43           ` Ralf Habacker
2001-12-30  5:03             ` Christopher Faylor
2001-12-30  7:34               ` Ralf Habacker
2001-12-30 11:56                 ` Christopher Faylor
2001-12-31 11:19                   ` Ralf Habacker
2002-01-01  7:07                     ` Corinna Vinschen
2002-01-01 16:00                       ` Ralf Habacker
2002-01-02  2:04                         ` Corinna Vinschen
2002-01-02  2:11                           ` Ralf Habacker
2001-12-29 14:15           ` Ralf Habacker
2001-12-29 16:40           ` Ralf Habacker
2001-12-30 14:35             ` Christopher Faylor
2001-12-30 16:42               ` Christopher Faylor
2001-12-31  1:16                 ` Christopher Faylor
2001-12-31  2:42               ` Ralf Habacker
2001-12-31 11:06                 ` Christopher Faylor
2001-12-31 12:04                   ` Ralf Habacker
2001-12-31 14:12                     ` Christopher Faylor
     [not found] <01df01c19259$1cbb8300$0200a8c0@lifelesswks>
2002-01-01  6:27 ` Ralf Habacker
2002-01-01  9:26   ` Christopher Faylor
2002-01-01  9:53     ` Corinna Vinschen
2002-01-01 10:30       ` Christopher Faylor
2002-01-01 13:56     ` Ralf Habacker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000401c18efb$18115890$0e6307d5@BRAMSCHE' \
    --to=ralf.habacker@freenet.de \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).