Re: mailman on OpenBSD - linking problem

[Odhiambo Washington]

On Sat, Mar 16, 2024 at 6:00 PM Stuart Henderson 
wrote:

> On 2024-03-16, Odhiambo Washington  wrote:
> >
> > On Sat, Mar 16, 2024 at 3:57=E2=80=AFPM Mark 
> wr=
> > ote:
> >
> >> On Wed, Mar 13, 2024 at 5:44=E2=80=AFPM Odhiambo Washington
>  > il.com>
> >> wrote:
> >>
> >>>
> >>> This is why I suggested he should run Mailman3 from the word go.
> >>>
> >>>
> >>>
> >> It looks almost impossible to setup Mailman3 on OpenBSD.
> >>
> >> No, this is not working at all;
> >> https://xn--gckvb8fzb.com/mailman3-on-openbsd-71/
> >>
> >> Any other tutorial I could try?
> >>
> >> Thank you.
> >>
> >
> > What exactly isn't working for you?
>
> Yes, this is a key thing when asking questions. Saying "No, this is not
> working at all" followed by a URL is not much help. Copy text from
> a terminal, showing _what commands you ran_ and _what you saw_.
>
> > The setup is actually pretty easy.
>
> mailman itself should be fairly easy to get installed in a venv, but
> mailman-web pulls in cryptography and that can be problematic sometimes.
> Trying to build that via pip isn't working at the moment in -current:
>
>   error: failed to run custom build command for `openssl-sys v0.9.99`
> ...
> This crate is only compatible with OpenSSL (version 1.0.1
> through 1.1.1, or 3), or LibreSSL 2.5 through 3.8.1, but a
> different version of OpenSSL was found. The build is now
> aborting due to this version mismatch.
>
> - so you'll probably have better luck by installing py3-cryptography
> from packages (when built in ports, openssl-sys is automatically
> patched to fix this problem), and when you create the venv, use
> --system-site-packages to allow the system package to be used.
>
> *However*, if you're doing this on a system which already has various
> python packages installed, using this may result in some conflicts with
> other software, so if you run into problems from that and can't
> uninstall the relevant package, you may need to use a fairly clean
> machine.
>
> (The ideal thing would be to get mailman updated to 3.x in ports,
> but looking at 'pip list' after installing mailman and mailman-web
> in a venv, there are 84 modules installed, getting on for 40 not
> in ports yet, and some of the others probably need updating -
> possibly with a ripple effect on other ports - so it's a lot of
> work; running in a venv with most things installed via pip is
> a saner option).
>

>From my own experience, running Mailman3 from OS packages/ports is fraught
with pain. It's also not supported by the Mailman Developers.
I have seen admins using Linux packages suffering from them. I am new to
OpenBSD, but have used FreeBSD for decades and still saw
lots of suffering getting Mailman3 installed from the ports. I had to
settle for the virtualenv option and found it to be rock solid.
The official documentation for Mailman3 is so Linux-centric and recommends
virtualenv 
option.
It's pretty easy to setup.
For the *BSD the biggest challenge is how to launch the processes (mailman
core and mailman-web) on system startup. However, there are ways:
supervisord, cron, etc. I use a startup script on my FreeBSD server. I use
Exim as MTA, Apache as the web server.
I am positive that @Mark  will manage fairly
easily with the virtualenv method I shared previously. He can use the
OpenBSD-centric applications
as documented or opt for the *easier* ones like I do on FreeBSD :-)


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
 In an Internet failure case, the #1 suspect is a constant: DNS.
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
[How to ask smart questions:
http://www.catb.org/~esr/faqs/smart-questions.html]

Re: mailman on OpenBSD - linking problem

[Stuart Henderson]

On 2024-03-16, Odhiambo Washington  wrote:
>
> On Sat, Mar 16, 2024 at 3:57=E2=80=AFPM Mark  wr=
> ote:
>
>> On Wed, Mar 13, 2024 at 5:44=E2=80=AFPM Odhiambo Washington  il.com>
>> wrote:
>>
>>>
>>> This is why I suggested he should run Mailman3 from the word go.
>>>
>>>
>>>
>> It looks almost impossible to setup Mailman3 on OpenBSD.
>>
>> No, this is not working at all;
>> https://xn--gckvb8fzb.com/mailman3-on-openbsd-71/
>>
>> Any other tutorial I could try?
>>
>> Thank you.
>>
>
> What exactly isn't working for you?

Yes, this is a key thing when asking questions. Saying "No, this is not
working at all" followed by a URL is not much help. Copy text from
a terminal, showing _what commands you ran_ and _what you saw_.

> The setup is actually pretty easy.

mailman itself should be fairly easy to get installed in a venv, but
mailman-web pulls in cryptography and that can be problematic sometimes.
Trying to build that via pip isn't working at the moment in -current:

  error: failed to run custom build command for `openssl-sys v0.9.99`
...
This crate is only compatible with OpenSSL (version 1.0.1
through 1.1.1, or 3), or LibreSSL 2.5 through 3.8.1, but a
different version of OpenSSL was found. The build is now
aborting due to this version mismatch.

- so you'll probably have better luck by installing py3-cryptography
from packages (when built in ports, openssl-sys is automatically
patched to fix this problem), and when you create the venv, use
--system-site-packages to allow the system package to be used.

*However*, if you're doing this on a system which already has various
python packages installed, using this may result in some conflicts with
other software, so if you run into problems from that and can't
uninstall the relevant package, you may need to use a fairly clean
machine.

(The ideal thing would be to get mailman updated to 3.x in ports,
but looking at 'pip list' after installing mailman and mailman-web
in a venv, there are 84 modules installed, getting on for 40 not
in ports yet, and some of the others probably need updating -
possibly with a ripple effect on other ports - so it's a lot of
work; running in a venv with most things installed via pip is
a saner option).


-- 
Please keep replies on the mailing list.

Re: mailman on OpenBSD - linking problem

[Odhiambo Washington]

On Sat, Mar 16, 2024 at 3:57 PM Mark  wrote:

> On Wed, Mar 13, 2024 at 5:44 PM Odhiambo Washington 
> wrote:
>
>>
>> This is why I suggested he should run Mailman3 from the word go.
>>
>>
>>
> It looks almost impossible to setup Mailman3 on OpenBSD.
>
> No, this is not working at all;
> https://xn--gckvb8fzb.com/mailman3-on-openbsd-71/
>
> Any other tutorial I could try?
>
> Thank you.
>

What exactly isn't working for you? The setup is actually pretty easy.
Feel free to discuss the setup offlist.


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
 In an Internet failure case, the #1 suspect is a constant: DNS.
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
[How to ask smart questions:
http://www.catb.org/~esr/faqs/smart-questions.html]

Re: mailman on OpenBSD - linking problem

[Mark]

On Wed, Mar 13, 2024 at 5:44 PM Odhiambo Washington 
wrote:

>
> This is why I suggested he should run Mailman3 from the word go.
>
>
>
It looks almost impossible to setup Mailman3 on OpenBSD.

No, this is not working at all;
https://xn--gckvb8fzb.com/mailman3-on-openbsd-71/

Any other tutorial I could try?

Thank you.

Re: mailman on OpenBSD - linking problem

[Odhiambo Washington]

On Wed, Mar 13, 2024 at 1:58 PM Michael Hekeler  wrote:

> > Anything else I should pay attention to?
>
> Make sure that your TLS setup is okay.
> Read mailman's docs and also the pkg-readme (e.g. setting up cronjobs)
> - and pay attention to configuration of your mailserver
>
>
> > It's a basic mailing list for few gaming discussions really,
> > so escaping from chroot was not really that scary, at least in that case.
>
> I wouldn't deploy old python scripts outside chroot (python 2.7 was
> end-of-life since 01.01.2020!)
>

This is why I suggested he should run Mailman3 from the word go.

...but I also think I wouldn't setup any huge software just to deploy
> "a basic mailing list for few gaming discussions"
>

They can us WhatsApp/Telegram/etc ? :-)


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
 In an Internet failure case, the #1 suspect is a constant: DNS.
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
[How to ask smart questions:
http://www.catb.org/~esr/faqs/smart-questions.html]

Re: mailman on OpenBSD - linking problem

[Michael Hekeler]

> Anything else I should pay attention to?

Make sure that your TLS setup is okay.
Read mailman's docs and also the pkg-readme (e.g. setting up cronjobs)
- and pay attention to configuration of your mailserver


> It's a basic mailing list for few gaming discussions really,
> so escaping from chroot was not really that scary, at least in that case.
 
I wouldn't deploy old python scripts outside chroot (python 2.7 was
end-of-life since 01.01.2020!)
...but I also think I wouldn't setup any huge software just to deploy
"a basic mailing list for few gaming discussions"

Re: mailman on OpenBSD - linking problem

[Mark]

On Tue, Mar 12, 2024 at 8:52 PM Michael Hekeler  wrote:

> But please keep in mind that you have disabled chroot and this is not
> recommended.
> Maybe you want to consider to copy the needed files inside the chroot?
> Or perhaps deploy mailman with something like gunicorn or uwsgi?
>
>
Hi Michael,
Thanks a lot for the suggestions and tips.

It's a basic mailing list for few gaming discussions really,
so escaping from chroot was not really that scary, at least in that case.
OpenBSD, even unchrooted, is rock solid! No? :)

After your suggestions, the latest httpd.conf is as follows;

location "/" {
block return 302 "/listinfo"
}

location "/icons/*" {
root "/usr/local/lib/mailman/icons/"
request strip 1
}

location "/pipermail/*" {
root "/var/spool/mailman/archives/public"
request strip 1
}

location "/*" {
fastcgi socket "/var/www/run/slowcgi.sock"
root "/usr/local/lib/mailman/cgi-bin"
}

my httpd.conf is much cleaner and simpler now, thanks to you guys all,
it seems everything is all set now.

Anything else I should pay attention to?

Best,
Mark.

Re: mailman on OpenBSD - linking problem

[Michael Hekeler]

> What does "request strip 1" actually do in that case?

>From the manpage:
Strip strips path components from the beginning of the request path
before looking up the stripped-down path at the document root.

So in your case:
location "/admin/*" {
fastcgi socket "/var/www/run/slowcgi.sock"
root "/usr/local/lib/mailman/cgi-bin/admin"
request strip 1
}
if request is "admin/" then "admin" is stripped and "/" is sent to
document_root.


> The cgi files are in /usr/local/lib/mailman/cgi-bin/
> chroot setting in httpd.conf: chroot "/"
> Slowcgi starts with: slowcgi_flags="-p /" and it's socket path is:
> /var/www/run/slowcgi.sock
> 
> Slowcgi and httpd works fine. However two things I'd like to know;
> 
> As I asked, what does "request strip 1" do and if I really need that?
> 
> Secondly; how to combine two locations into one? So that;
> "/admin" and "/admin/" would get captured both.

So you expect the location to be triggered if the request is "admin"
but you configured the location to listen on "admin/"?
See the difference?

Next:
There is another misconfiguration in your http.conf: You use root
directive with a filename? Why? Manpage says: The directory is a
pathname within the chroot(2) root directory of httpd.
If you set root to a filename then you have to create multiple locations
for every request:
location "/admin"--> root "/usr/local/lib/mailman/cgi-bin/admin"
location "/list" --> root "/usr/local/lib/mailman/cgi-bin/list"
location "/foo"  --> root "/usr/local/lib/mailman/cgi-bin/foo"
...
this could be quite tedious thats why I would suggest:
location "/*" --> root "/usr/local/lib/mailman/cgi-bin"


If you want mailman act on something like http://localhost/mailman/admin
then you can do:
location "/mailman/*" {
fastcgi
root "/usr/local/lib/mailman/cgi-bin"
request strip 1
}

But please keep in mind that you have disabled chroot and this is not
recommended.
Maybe you want to consider to copy the needed files inside the chroot?
Or perhaps deploy mailman with something like gunicorn or uwsgi?

Re: mailman on OpenBSD - linking problem

[Rob Schmersel]

On Mon, 11 Mar 2024 21:16:05 +0300
Mark  wrote:

> On Mon, Mar 11, 2024 at 11:16 AM Michael Hekeler 
> wrote:
> 
> > I don't know this mailman script but...
> > Why did you strip first component from the request?
> > Are these cgi's in /usr/local/lib/mailman/cgi-bin/admin or in
> > /var/www/usr/local/lib/mailman/cgi-bin/admin?
> > What is your chroot setting in httpd.conf?
> > And IF you changed httpd chroot how do you start slowcgi(8)?
> > What/where is socket? Where is path?
> >
> >  
> Hi Michael,
> 
> What does "request strip 1" actually do in that case?
> The cgi files are in /usr/local/lib/mailman/cgi-bin/
> chroot setting in httpd.conf: chroot "/"
> Slowcgi starts with: slowcgi_flags="-p /" and it's socket path is:
> /var/www/run/slowcgi.sock
> 
> Slowcgi and httpd works fine. However two things I'd like to know;
> 
> As I asked, what does "request strip 1" do and if I really need that?
> 
> Secondly; how to combine two locations into one? So that;
> "/admin" and "/admin/" would get captured both.

you would have 2 locations like this
location match "/admin" {
request rewrite "/admin/"
}
location "/admin/" {
...
}

you should be able to generalize the 1st match to add a / to every
request not having a / at the end when it is not pointing to a file
(*.html/png/...) with something like this (note I've not tested this,
so use at own risk :) )

location match "([^.]+)[^/]$" {
request rewrite "%1/"
}

Re: mailman on OpenBSD - linking problem

[Mark]

On Mon, Mar 11, 2024 at 11:16 AM Michael Hekeler 
wrote:

> I don't know this mailman script but...
> Why did you strip first component from the request?
> Are these cgi's in /usr/local/lib/mailman/cgi-bin/admin or in
> /var/www/usr/local/lib/mailman/cgi-bin/admin?
> What is your chroot setting in httpd.conf?
> And IF you changed httpd chroot how do you start slowcgi(8)?
> What/where is socket? Where is path?
>
>
Hi Michael,

What does "request strip 1" actually do in that case?
The cgi files are in /usr/local/lib/mailman/cgi-bin/
chroot setting in httpd.conf: chroot "/"
Slowcgi starts with: slowcgi_flags="-p /" and it's socket path is:
/var/www/run/slowcgi.sock

Slowcgi and httpd works fine. However two things I'd like to know;

As I asked, what does "request strip 1" do and if I really need that?

Secondly; how to combine two locations into one? So that;
"/admin" and "/admin/" would get captured both.

Best wishes,
Mark.

Re: mailman on OpenBSD - linking problem

[Michael Hekeler]

> I set up a mailman on OpenBSD, and it seems I have managed to do it.
> 
> A single problem left, that I'd like to share with you and get your idea;
> 
> On mailman homepage, there is a link "you can visit the list admin overview
> page"
> and when I click, redirects me: mysite.com/admin and it gives error 404.
> 
> However if I add "/" at the end, making mysite.com/admin/, it works.
> 
> Also the same happens on the linked-text;
> "Overview of all list.mysite.com mailing lists" linking to;
> mysite.com/listinfo, which gives 404 not found when clicking on it.
> 
> But with an extra '/'; mysite.com/listinfo/ works.
> 
> Where's my mistake?
> 
> Related httpd.conf lines;
> 
> location "/admin/*" {
> fastcgi socket "/var/www/run/slowcgi.sock"
> root "/usr/local/lib/mailman/cgi-bin/admin"
> request strip 1
> }

I don't know this mailman script but...
Why did you strip first component from the request?
Are these cgi's in /usr/local/lib/mailman/cgi-bin/admin or in
/var/www/usr/local/lib/mailman/cgi-bin/admin?
What is your chroot setting in httpd.conf?
And IF you changed httpd chroot how do you start slowcgi(8)?
What/where is socket? Where is path?

mailman on OpenBSD - linking problem

[Mark]

Hi.

I set up a mailman on OpenBSD, and it seems I have managed to do it.

A single problem left, that I'd like to share with you and get your idea;

On mailman homepage, there is a link "you can visit the list admin overview
page"
and when I click, redirects me: mysite.com/admin and it gives error 404.

However if I add "/" at the end, making mysite.com/admin/, it works.

Also the same happens on the linked-text;
"Overview of all list.mysite.com mailing lists" linking to;
mysite.com/listinfo, which gives 404 not found when clicking on it.

But with an extra '/'; mysite.com/listinfo/ works.

Where's my mistake?

Related httpd.conf lines;

location "/admin/*" {
fastcgi socket "/var/www/run/slowcgi.sock"
root "/usr/local/lib/mailman/cgi-bin/admin"
request strip 1
}

location "/listinfo/*" {
fastcgi socket "/var/www/run/slowcgi.sock"
root "/usr/local/lib/mailman/cgi-bin/listinfo"
request strip 1
}

Regards,
Mark.

issues linking on OpenBSD i386 (has non-ABS relocation R_386_GOTOFF against symbol)

[Riccardo Mottola]

Hi,

I was doing some compilations on OpenBSD 6.8 i386 using gcc 8.4 
available from pkg.


When compiling gnustep-gui current GIT (tests before release), I get 
this error:


ld: error: NSPrintOperation.m:(.debug_info+0x2FE631): has non-ABS 
relocation R_386_GOTOFF against symbol '_OBJC_INSTANCE_7.23243'


I tried both using ld and ld.bfd . In the past it used to compile link & 
run on OpenBSD with gcc, with 6.7 thouhg, i updated to 6.8 relatively late.


A common suggestion I found would be using ld.gold, but I couldn't find 
it for OpenBSD! is it in a separate package to install?


At first, I thought an issue specific to GNUstep when build with gcc, 
but then I tried building ArcticFox browser with the same gcc. There I 
get these:


 1:28.82 cd mangle; /usr/local/bin/gmake export
 1:28.82 ld: error: prprf.c:(.debug_info+0x193FD): has non-ABS 
relocation R_386_GOTOFF against symbol '.LC5'
 1:28.82 ld: error: prdtoa.c:(.debug_info+0x3865E): has non-ABS 
relocation R_386_GOTOFF against symbol '.LSSH2'
 1:28.82 ld: error: ptio.c:(.debug_info+0x5FB43): has non-ABS 
relocation R_386_GOTOFF against symbol '.LSSH22'
 1:28.82 ld: error: praton.c:(.debug_info+0x4A112): has non-ABS 
relocation R_386_GOTOFF against symbol '.LSSH0'


I see a pattern here then!


I was able to compile ArcticFox - same code base, using system clang 
however.
I did not try GNustep with clang, because it requires libobjc2 and that 
has other issues for the moment. Also both software compile with gcc 
equivalent version on NetBSD, FreeBSD and different Linux.


Any suggestions with these linking issues?

Riccardo

PostgreSQL-Libpq linking warnings

[Kihaguru Gathura]

Hi,

The warnings below always appear while linking c files with
postgresql-libpq on SPARC64 platform. Arm64 and i386 platforms don't
display these errors.

/usr/local/lib/libpq.a(fe-auth.o): In function `PQencryptPasswordConn':
fe-auth.c:(.text+0x284): warning: strcpy() is almost always misused, please
use strlcpy()
/usr/local/lib/libpq.a(fe-connect.o): In function `internal_cancel':
fe-connect.c:(.text+0x30f0): warning: strcat() is almost always misused,
please use strlcat()
/usr/local/lib/libpq.a(fe-connect.o): In function `PQsetClientEncoding':
fe-connect.c:(.text+0xad4): warning: sprintf() is often misused, please use
snprintf()

Can the changes be effected at packages or does it have to be solved by
postgresql team?

Thanks and Regards,

Kihaguru

Re: question about man starttls and linking to cert.pem

[Todd C . Miller]

On Sun, 11 Aug 2019 16:03:39 +0200, Gilles Chehade wrote:

> It's interesting to have instruction for generating self-signed cert but
> most people will want a cert that others will validate so it makes sense
> to at least extend the man page (in another diff) in my opinion.

And if we do that we should also at least mention MTA-STS.

 - todd

Re: question about man starttls and linking to cert.pem

[Gilles Chehade]

On Sun, Aug 11, 2019 at 07:17:06AM -0600, Todd C. Miller wrote:
> On Sat, 10 Aug 2019 22:22:05 -0400, "Ted Unangst" wrote:
> 
> > That entire section seems dumb and outdated. I would prefer we
> > simply not give any advice here. Users can figure out what they
> > need to do. Installing the public cert needs to be done on many
> > other machines, not just the one where its generated.
> 
> Fine with me.  I wonder if we shouldn't also mention acme-client
> here too.  Something for another diff...
> 

I was wondering the same actually.

It's interesting to have instruction for generating self-signed cert but
most people will want a cert that others will validate so it makes sense
to at least extend the man page (in another diff) in my opinion.

-- 
Gilles Chehade @poolpOrg

https://www.poolp.orgpatreon: https://www.patreon.com/gilles

Re: question about man starttls and linking to cert.pem

[Todd C . Miller]

On Sat, 10 Aug 2019 22:22:05 -0400, "Ted Unangst" wrote:

> That entire section seems dumb and outdated. I would prefer we
> simply not give any advice here. Users can figure out what they
> need to do. Installing the public cert needs to be done on many
> other machines, not just the one where its generated.

Fine with me.  I wonder if we shouldn't also mention acme-client
here too.  Something for another diff...

 - todd

Re: question about man starttls and linking to cert.pem

[Chris Bennett]

Thanks, that had me confused when I read it, so I just ignored it.
Glad to know I did, as in didn't, do what it suggested except once.

Chris Bennett

Re: question about man starttls and linking to cert.pem

[Ted Unangst]

freda_bundc...@nym.hush.com wrote:
> Description:
> man starttls says one can link a new certificate to cert.pem with
> ln -s /etc/ssl/mail.example.com.crt /etc/ssl/cert.pem if one does not 
> intend

That entire section seems dumb and outdated. I would prefer we simply not give
any advice here. Users can figure out what they need to do. Installing the
public cert needs to be done on many other machines, not just the one where
it's generated.

Index: starttls.8
===
RCS file: /home/cvs/src/share/man/man8/starttls.8,v
retrieving revision 1.26
diff -u -p -r1.26 starttls.8
--- starttls.8  27 Jun 2018 05:39:02 -  1.26
+++ starttls.8  11 Aug 2019 02:20:01 -
@@ -102,18 +102,6 @@ with the following command:
 .Pp
 .Dl # openssl x509 -in /etc/ssl/mail.example.com.crt -text
 .Pp
-If you don't intend to use TLS for authentication (and if you are using
-self-signed certificates you probably don't) you can simply link
-your new certificate to
-.Pa cert.pem :
-.Pp
-.Dl # ln -s /etc/ssl/mail.example.com.crt /etc/ssl/cert.pem
-.Pp
-If, on the other hand, you intend to use TLS for authentication
-you should add your certificate authority bundle to
-.Pa /etc/ssl/cert.pem
-(or whatever your software expects).
-.Pp
 Because the private key files are unencrypted,
 MTAs can be picky about using tight permissions on those files.
 The certificate directory and the files therein should be

question about man starttls and linking to cert.pem

[freda_bundchen]

Synopsis:man starttls linking new certificate to cert.pem problem
Category:documentation
Environment:
System  : OpenBSD 6.5
Details : OpenBSD 6.5-current (GENERIC.MP) #184: Wed Aug  7 21:37:16 
MDT 2019
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
Description:
man starttls says one can link a new certificate to cert.pem with
ln -s /etc/ssl/mail.example.com.crt /etc/ssl/cert.pem if one does not 
intend
but link will
fail since /etc/ssl/cert.pem exists already
How-To-Repeat:
man starttls

I apologize, maybe it's not an error at all, so I'm writing to misc instead 
of bugs.
I don't understand why one create this link, and I haven't been able to find an 
explanation 
on the lists or elsewhere. Any explanation would be greatly appreciated.

The reason I am asking about it is  that I am forwarding all mail from
one server to another using starttls and opensmtpd, and it works fine with tls 
no-verify
without creating the link to cert.pem. Also, if one does create the
link (perhaps backing up cert.pem first) then sysupgrade will fail
since it expects the original cert.pem. Also if running unbound, one
would need to use the original cert.pem (or whatever it was renamed to)
if using tls-bundle and DNS-over-TLS, I think.

linking libqb on openbsd fails

[Jiri B]

Hi,

I try to build libqb library and it fails with following output, any idea
what could be wrong there?

Originally reported at https://github.com/ClusterLabs/libqb/issues/299

(libqb is prerequisite for corosync/pacemaker stuff)

Jiri

=2E..
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I../include -I../include/qb -I..=
/include -I../include -O2 -pipe -Wall -Wextra -Wunused -Wshadow -Wmissing-p=
rototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wwrit=
e-strings -Wcast-align -Wbad-function-cast -Wmissing-format-attribute -Wflo=
at-equal -Wformat=3D2 -Woverlength-strings -Winit-self -Wuninitialized -Wun=
known-pragmas -Wno-unused-parameter -Wno-format-nonliteral -Wno-sign-compar=
e -MT strchrnul.lo -MD -MP -MF .deps/strchrnul.Tpo -c strchrnul.c  -fPIC -D=
PIC -o .libs/strchrnul.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I../include -I../include/qb -I..=
/include -I../include -O2 -pipe -Wall -Wextra -Wunused -Wshadow -Wmissing-p=
rototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wwrit=
e-strings -Wcast-align -Wbad-function-cast -Wmissing-format-attribute -Wflo=
at-equal -Wformat=3D2 -Woverlength-strings -Winit-self -Wuninitialized -Wun=
known-pragmas -Wno-unused-parameter -Wno-format-nonliteral -Wno-sign-compar=
e -MT strchrnul.lo -MD -MP -MF .deps/strchrnul.Tpo -c strchrnul.c -o strchr=
nul.o >/dev/null 2>&1
cc -E -xc -I../include -D_GNU_SOURCE -C -P qblog_script.ld.in \
  | sed -n "/$(sed -n '/^[^#]/{s/[*\/]/\\&/g;p;q;}' qblog_script.ld.in)/,$ =
p" \
  > qblog_script.ld
/usr/local/bin/libtool  --tag=3DCC   --mode=3Dlink cc -pthread -O2 -pipe   =
   -Wall -Wextra -Wunused -Wshadow -Wmissing-prototypes -Wmissing-declarati=
ons -Wstrict-prototypes -Wpointer-arith -Wwrite-strings -Wcast-align -Wbad-=
function-cast -Wmissing-format-attribute -Wfloat-equal -Wformat=3D2 -Woverl=
ength-strings -Winit-self -Wuninitialized -Wunknown-pragmas -Wno-unused-par=
ameter -Wno-format-nonliteral -Wno-sign-compare  -version-info 19:0:19  -o =
libqb.la -rpath /usr/local/lib libqb_la-util.lo libqb_la-hdb.lo libqb_la-ri=
ngbuffer.lo libqb_la-ringbuffer_helper.lo libqb_la-array.lo libqb_la-loop.l=
o libqb_la-loop_poll.lo libqb_la-loop_job.lo libqb_la-loop_timerlist.lo lib=
qb_la-ipcc.lo libqb_la-ipcs.lo libqb_la-ipc_shm.lo libqb_la-ipc_setup.lo li=
bqb_la-ipc_socket.lo libqb_la-log.lo libqb_la-log_thread.lo libqb_la-log_bl=
ackbox.lo libqb_la-log_file.lo libqb_la-log_syslog.lo libqb_la-log_dcs.lo l=
ibqb_la-log_format.lo libqb_la-map.lo libqb_la-skiplist.lo libqb_la-hashtab=
le.lo libqb_la-trie.lo libqb_la-unix.lo   libqb_la-loop_poll_kqueue.lo  str=
chrnul.loqblog_script.la=20

*** Warning: This system can not link to static lib archive qblog_script.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
libtool: link: cc -shared  -fPIC -DPIC -o .libs/libqb.so.19.0  .libs/libqb_=
la-util.o .libs/libqb_la-hdb.o .libs/libqb_la-ringbuffer.o .libs/libqb_la-r=
ingbuffer_helper.o .libs/libqb_la-array.o .libs/libqb_la-loop.o .libs/libqb=
_la-loop_poll.o .libs/libqb_la-loop_job.o .libs/libqb_la-loop_timerlist.o .=
libs/libqb_la-ipcc.o .libs/libqb_la-ipcs.o .libs/libqb_la-ipc_shm.o .libs/l=
ibqb_la-ipc_setup.o .libs/libqb_la-ipc_socket.o .libs/libqb_la-log.o .libs/=
libqb_la-log_thread.o .libs/libqb_la-log_blackbox.o .libs/libqb_la-log_file=
=2Eo .libs/libqb_la-log_syslog.o .libs/libqb_la-log_dcs.o .libs/libqb_la-lo=
g_format.o .libs/libqb_la-map.o .libs/libqb_la-skiplist.o .libs/libqb_la-ha=
shtable.o .libs/libqb_la-trie.o .libs/libqb_la-unix.o .libs/libqb_la-loop_p=
oll_kqueue.o .libs/strchrnul.o-pthread -O2 -pthread   -pthread -Wl,/usr=
/ports/pobj/libqb-1.0.3/libqb-1.0.3/lib/qblog_script.ld
/usr/bin/ld: section __verbose [002351f8 -> 00236a7f] overl=
aps section .bss [00225060 -> 00235f87]
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [Makefile:740: libqb.la] Error 1
gmake[2]: Leaving directory '/usr/ports/pobj/libqb-1.0.3/libqb-1.0.3/lib'
gmake[1]: *** [Makefile:513: all-recursive] Error 1
gmake[1]: Leaving directory '/usr/ports/pobj/libqb-1.0.3/libqb-1.0.3'
gmake: *** [Makefile:438: all] Error 2
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2742 '/usr/ports=
/pobj/libqb-1.0.3/.build_done')
*** Error 1 in /usr/ports/devel/libqb (/usr/ports/infrastructure/mk/bsd.por=
t.mk:2419 'all')

$ sysctl kern.version  =
   =
  =20
kern.version=3DOpenBSD 6.3-beta (GENERIC) #25: Fri Mar  2 22:51:43 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

$ /usr/ports/pobj/libqb-1.0.3/bin/cc -v=20
OpenBSD clang version 5.0.1 (tags/RELEASE_501/final) (based on L

Re: Linking the amd64 Kernel with ld.lld (further more have the default system linker as ld.lld)

[Stuart Henderson]

On 2017-12-15, Adam Steen  wrote:
> Hi All
>
> Do you know if its possible to link the amd64 kernel with ld.lld? and
> if so would you change LD?= in sys.mk?
>
> I haven't been able to find anything about this besides "Bug 30815 -
> linking OpenBSD/amd64 kernel" [1]. Which says the linked kernel
> doesn't boot, thus if we can't link the kernel with ld.lld, the
> default system linker is a non-starter.
>
> Is this a direction the project wants to head?
>
> Cheers
> Adam
>
> [1] https://bugs.llvm.org/show_bug.cgi?id=30815
>
>

There are definitely some advantages to switching to lld. espie@ made a
bunch of fixes in ports-land for this. 

Seems like it would be easy enough to test whether an amd64 kernel
linked in this way is bootable. The method in the ticket you linked
should be good enough for a test.

Note that OpenBSD/arm64 is all clang/lld, binutils is not built there.

Linking the amd64 Kernel with ld.lld (further more have the default system linker as ld.lld)

[Adam Steen]

Hi All

Do you know if its possible to link the amd64 kernel with ld.lld? and
if so would you change LD?= in sys.mk?

I haven't been able to find anything about this besides "Bug 30815 -
linking OpenBSD/amd64 kernel" [1]. Which says the linked kernel
doesn't boot, thus if we can't link the kernel with ld.lld, the
default system linker is a non-starter.

Is this a direction the project wants to head?

Cheers
Adam

[1] https://bugs.llvm.org/show_bug.cgi?id=30815

Linking gdb errors when compiling -current src tree

[Nan Xiao]

Hi misc@,

Greetings from me!

I am trying to follow this link
(https://man.openbsd.org/release#3._Build_a_new_base_system) to build
base system of -current src tree.

But unfortunately, I come across following error in linking gdb:

cc -O2 -pipe  -DPIE_DEFAULT=1 -o gdb gdb.o libgdb.a
../bfd/libbfd.a -lreadline ../opcodes/libopcodes.a  -liberty
-lncurses -lm -liberty  -lkvm
libgdb.a(main.o): In function `captured_main':
/usr/src/gnu/usr.bin/binutils/gdb/main.c:(.text+0x7e6): warning:
warning: strcpy() is almost always misused, please use strlcpy()
/usr/src/gnu/usr.bin/binutils/gdb/main.c:(.text+0x7ff): warning:
warning: strcat() is almost always misused, please use strlcat()
libgdb.a(target.o): In function `normal_pid_to_str':
/usr/src/gnu/usr.bin/binutils/gdb/target.c:(.text+0x3047): warning:
warning: sprintf() is often misused, please use snprintf()
libgdb.a(main.o): In function `captured_main':
/usr/src/gnu/usr.bin/binutils/gdb/main.c:(.text+0xa4): undefined
reference to `bindtextdomain'
/usr/src/gnu/usr.bin/binutils/gdb/main.c:(.text+0xac): undefined
reference to `textdomain'
/usr/src/gnu/usr.bin/binutils/gdb/main.c:(.text+0x4b7): undefined
reference to `dcgettext'
/usr/src/gnu/usr.bin/binutils/gdb/main.c:(.text+0x606): undefined
reference to `dcgettext'
/usr/src/gnu/usr.bin/binutils/gdb/main.c:(.text+0x78d): undefined
reference to `dcgettext'
/usr/src/gnu/usr.bin/binutils/gdb/main.c:(.text+0x9b9): undefined
reference to `dcgettext'
/usr/src/gnu/usr.bin/binutils/gdb/main.c:(.text+0xa60): undefined
reference to `dcgettext'
libgdb.a(main.o):/usr/src/gnu/usr.bin/binutils/gdb/main.c:(.text+0xb46):
more undefined references to `dcgettext' follow
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error 1 in gnu/usr.bin/binutils/obj/gdb (Makefile:1176 'gdb')
*** Error 1 in gnu/usr.bin/binutils/obj (Makefile:21479 'all-gdb')
*** Error 1 in gnu/usr.bin/binutils (Makefile.bsd-wrapper:46 'all')
*** Error 1 in gnu/usr.bin (:48 'all')
*** Error 1 in gnu (:48 'all')
*** Error 1 in . (:48 'all')
*** Error 1 in . (Makefile:95 'do-build')
*** Error 1 in /usr/src (Makefile:74 'build')

Could anyone give some clues about this issue?

Thanks very much in advance!

Best Regards
Nan Xiao

Re: Port Solo5 to OpenBSD - Linking Problem (recompile with -fPIC)

[Philip Guenther]

On Fri, 16 Jun 2017, Adam Steen wrote:
> I am attempting to port Solo5 to OpenBSD (Virtio only), I think i have 
> the kernel and test_hello compiling but when it comes to linking 
> test_hello i get the following error.
> 
> /home/asteen/devl/solo5/kernel/virtio/solo5.o: relocation R_X86_64_32
> against 'a local symbol' can not be used when making a shared object;
> recompile with -fPIC [1]
...
> clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -isystem
> /home/asteen/devl/solo5/include-host -std=gnu99 -Wall -Wextra -Werror
> -O2 -g -I/home/asteen/devl/solo5/kernel -c test_hello.c -o
> test_hello.o

That part is okay.


> ld -T /home/asteen/devl/solo5/kernel/virtio/solo5.lds \
> -nostdlib -z max-page-size=0x1000 -static -o test_hello.virtio
> /home/asteen/devl/solo5/kernel/virtio/solo5.o test_hello.o

This part is not.  Projects aiming for portability should build both 
executable and shared libraries via the compiler driver ('clang', 'cc', or 
'gcc') and *not* by invoking ld directly.

This is because the objects generated by the C compiler may depend on the 
presence of symbols provided by objects or options supplied by the 
compiler driver.  That's true not just on OpenBSD but on Linux as well.


In this case, you've almost certainly hit the need for the __guard_local 
symbol, which is provided by crtbeginS.o

(Note: crtbeginS.o itself needs another object supplied by the compiler 
driver, so don't even _think_ of pulling it in manually!)


Philip Guenther

Re: Port Solo5 to OpenBSD - Linking Problem (recompile with -fPIC)

[Mihai Popescu]

> I am attempting to port Solo5

ports [ at] openbsd.org

Port Solo5 to OpenBSD - Linking Problem (recompile with -fPIC)

[Adam Steen]

Hi

I am attempting to port Solo5 to OpenBSD (Virtio only), I think i have
the kernel and test_hello compiling but when it comes to linking
test_hello i get the following error.

/home/asteen/devl/solo5/kernel/virtio/solo5.o: relocation R_X86_64_32
against 'a local symbol' can not be used when making a shared object;
recompile with -fPIC [1]

adding -fPIC to HOST_CFLAGS doesn't seem to help (HOST_CFLAGS="-fPIC
-nostdlibinc")

My changes to the configure script are located
(https://github.com/Solo5/solo5/compare/master...adamsteen:master)

Could anyone point me right direction to get this working? The full
build log is attached.

Cheers
Adam

PS I am new to c and make files, but i had to pick somewhere to start,
and solo5 has piqued my interest.

[1]
clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -isystem
/home/asteen/devl/solo5/include-host -std=gnu99 -Wall -Wextra -Werror
-O2 -g -I/home/asteen/devl/solo5/kernel -c test_hello.c -o
test_hello.o
ld -T /home/asteen/devl/solo5/kernel/virtio/solo5.lds \
-nostdlib -z max-page-size=0x1000 -static -o test_hello.virtio
/home/asteen/devl/solo5/kernel/virtio/solo5.o test_hello.o
ld: /home/asteen/devl/solo5/kernel/virtio/solo5.o: relocation
R_X86_64_32 against 'a local symbol' can not be used when making a
shared object; recompile with -fPIC
/home/asteen/devl/solo5/kernel/virtio/solo5.o: could not read symbols: Bad value
gmake[2]: *** [../Makefile.tests:64: test_hello.virtio] Error 1
gmake[2]: Leaving directory '/home/asteen/devl/solo5/tests/test_hello'
gmake[1]: *** [GNUmakefile:43: _test_virtio_hello] Error 2
gmake[1]: Leaving directory '/home/asteen/devl/solo5/tests'
gmake: *** [GNUmakefile:33: virtio] Error 2
gmake -C kernel virtio
gmake[1]: Entering directory '/home/asteen/devl/solo5/kernel'
clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -mno-sse -mno-mmx 
-mno-aes -mno-avx -isystem /home/asteen/devl/solo5/include-host -std=gnu99 
-Wall -Wextra -Werror -O2 -g -D__SOLO5_KERNEL__ -DASM_FILE -c virtio/boot.S -o 
virtio/boot.o
virtio/boot.S:38:1: warning: DWARF2 only supports one section per compilation 
unit
.section .data.multiboot
^
virtio/boot.S:51:1: warning: DWARF2 only supports one section per compilation 
unit
.section .bss
^
clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -mno-sse -mno-mmx 
-mno-aes -mno-avx -isystem /home/asteen/devl/solo5/include-host -std=gnu99 
-Wall -Wextra -Werror -O2 -g -D__SOLO5_KERNEL__ -c virtio/kernel.c -o 
virtio/kernel.o
clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -mno-sse -mno-mmx 
-mno-aes -mno-avx -isystem /home/asteen/devl/solo5/include-host -std=gnu99 
-Wall -Wextra -Werror -O2 -g -D__SOLO5_KERNEL__ -c virtio/platform.c -o 
virtio/platform.o
clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -mno-sse -mno-mmx 
-mno-aes -mno-avx -isystem /home/asteen/devl/solo5/include-host -std=gnu99 
-Wall -Wextra -Werror -O2 -g -D__SOLO5_KERNEL__ -c virtio/platform_intr.c -o 
virtio/platform_intr.o
clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -mno-sse -mno-mmx 
-mno-aes -mno-avx -isystem /home/asteen/devl/solo5/include-host -std=gnu99 
-Wall -Wextra -Werror -O2 -g -D__SOLO5_KERNEL__ -c virtio/pci.c -o virtio/pci.o
clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -mno-sse -mno-mmx 
-mno-aes -mno-avx -isystem /home/asteen/devl/solo5/include-host -std=gnu99 
-Wall -Wextra -Werror -O2 -g -D__SOLO5_KERNEL__ -c virtio/serial.c -o 
virtio/serial.o
clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -mno-sse -mno-mmx 
-mno-aes -mno-avx -isystem /home/asteen/devl/solo5/include-host -std=gnu99 
-Wall -Wextra -Werror -O2 -g -D__SOLO5_KERNEL__ -c virtio/time.c -o 
virtio/time.o
clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -mno-sse -mno-mmx 
-mno-aes -mno-avx -isystem /home/asteen/devl/solo5/include-host -std=gnu99 
-Wall -Wextra -Werror -O2 -g -D__SOLO5_KERNEL__ -c virtio/virtio_ring.c -o 
virtio/virtio_ring.o
clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -mno-sse -mno-mmx 
-mno-aes -mno-avx -isystem /home/asteen/devl/solo5/include-host -std=gnu99 
-Wall -Wextra -Werror -O2 -g -D__SOLO5_KERNEL__ -c virtio/virtio_net.c -o 
virtio/virtio_net.o
clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -mno-sse -mno-mmx 
-mno-aes -mno-avx -isystem /home/asteen/devl/solo5/include-host -std=gnu99 
-Wall -Wextra -Werror -O2 -g -D__SOLO5_KERNEL__ -c virtio/virtio_blk.c -o 
virtio/virtio_blk.o
clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -mno-sse -mno-mmx 
-mno-aes -mno-avx -isystem /home/asteen/devl/solo5/include-host -std=gnu99 
-Wall -Wextra -Werror -O2 -g -D__SOLO5_KERNEL__ -c virtio/tscclock.c -o 
virtio/tscclock.o
clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -mno-sse -mno-mmx 
-mno-aes -mno-avx -isystem /home/asteen/devl/solo5/include-host -std=gnu99 
-Wall -Wextra -Werror -O2 -g -D__SOLO5_KERNEL__ -c virtio/clock_subr.c -o 
virtio/clock_subr.o
clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -mno-sse -mn

Re: AMD64 packages - Reflecting dynamic linking

[Adam Thompson]

On 15-01-01 07:44 PM, Joel Rees wrote:

At the risk of having Theo tell me to shut up and get back to work on
things that matter, ...

and

I suppose it's inevitible that someone will want to control the world,
but I really wish you and your friends would quit lying to yourselves
about power.


I disagree - to me, this smells like just another instance of jwz's CADT 
(http://www.jwz.org/doc/cadt.html) cycle repeating itself.


To me, this means that the day approaches where systemd will have its 
very own invasive CADT movement to deal with - this thought gives me a 
rare example to use the word "schadenfreude" in regular conversation :).


--
-Adam Thompson
 athom...@athompso.net

Re: AMD64 packages - Reflecting dynamic linking

[Joel Rees]

At the risk of having Theo tell me to shut up and get back to work on
things that matter, ...

On Fri, Jan 2, 2015 at 1:33 AM, FRIGN  wrote:
> On Fri, 12 Dec 2014 20:02:33 +0100
> Ingo Schwarze  wrote:
>
>> There are dragons.
>
>> If this scares anybody, i'm not surprised; updating libraries is
>> not a playground for newbies.
>
>> That, actually, is *terrible* advice and almost guarantees a fiasco.
>> If you edit shlib_version manually, you build a library containing
>> code *incompatible* with what it's supposed to contain, so the end
>> result will be that programs using that library will, at run time,
>>  * crash,
>>  * produce obviously wrong results,
>>  * and/or silently produce results that are wrong in non-obvious ways.
>> Some programs, by mere luck, may also work, if you are lucky,
>> but it's hard to predict in advance which ones will and which
>> ones wont.
>
>> To update a library, update all related source code - ideally,
>> the whole source tree unless you know precisely what you are
>> doing - to one consistent state, than compile from that state
>> *without* manually screwing with shlib_version.  That's the whole
>> point of library versioning!
>
> I may get a little off-topic here and object for this very important
> topic to be discussed in a separate thread some day, but come to
> think of it, the overhead induced with dynamic linking, symbol
> versioning and crazy workarounds to make the dynamic linker remotely
> safe nowadays completely destroy the once good reasons for dynamic
> libraries.

Do I hear echos of the /usr argument? Speed and large drives "solve"
this one problem, so we can throw sense and reason out the window?

> Static linking eliminates all the issues involved with symbol versions,

If only we had perfect libraries to start with.

> wrecking your system with a library update and I'd even go as far
> as saying that static binaries are more or less independent from
> distributions.

As long as you ignore the inherent implicit linkages of the context
OSses and the tools being used at a certain point in time, sure,
theoretically, distribution independence can happen. Probably in the
same universe where openbsd is a Linux distribution. (But, then you
must remember to never argue that Linux Is Not UniX!)

> Memory usage is also not a point any more, because we
> have shared tables nowadays and in many cases, statically linked
> programs need less RAM than dynamically linked ones.

Even if your arguments were not random, would they be meaningful?

You not only fail to prove your assertions, you fail to explain their
relevance. Why?

> So, what are the remaining arguments against static linking?

What is your underlying argument? Static vs. dynamic is a null
argument, so you must be using it as noise cover to sell something
really noxious.

> I agree there are programs which do not run well if statically linked
> (the X-server for instance), but that's more or less a matter of design
> and can be worked around in most cases.

???

> One specific point often raised is the argument, that if you have
> an update for a specific library (a security update for instance),
> you just need to recompile the library and all programs depending
> on the library will behave correctly.
> With static libraries on the other hand, you would have to recompile
> all binaries and superset-libraries depending on this library for
> the security fix to be effective.
> This point is increasingly losing significance due to the following
> reasons:

Riding your noise waves, to look for clues, let's see:

> 1) hot-swapping a library for a security-fix implies that the ABI
> doesn't change, i.e. that the binaries on your system using this
> library can access the functions the way they have been told
> where they can find them.

So, you are saying that there are so many bugs in the APIs that it is
useless to fix non-API bugs? Cool. We can all go home now.

> In many cases nowadays, bugs are fixed concurrently with version
> bumps (major & minor) which means that all binaries have to be
> manually updated and recompiled anyway.

What do you mean by manually, anyway?

> 2) compiling is not expensive any more (in most cases).
> On my Gentoo-based system, it just takes 2 hours to recompile the
> entire operating system including all user-space applications.

Gee, I wish I had a 512 core 14GHz Intel Core 10 with 16 Terabytes of RAM ...

... and the requisite nuclear reactor to power it.

> Moore's law will decrease this time over the years significantly.

Intel's going to start shrinking silicon atoms now?

> Imagine if it just took 5 minutes,

as opposed to 5 seconds?

Why not? We're in the imagina

Re: AMD64 packages - Reflecting dynamic linking

[Jorge Gabriel Lopez Paramount]

Quoting FRIGN :


It may be a little far-fetched, but I'm sure it would be possible
to have one package-manager for all distributions if there would just
be the motivation to distribute statically linked binaries and not fuck
things up with distribution-specific folder-structures.


I'm not a hacker so I have no means to ponder your other arguments,  
but as a user you lost me with this. I'm running away from systemd so  
the concept of one package manager to rule them all does not appeal to  
me.


http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html

--
Best regards,
Jorge Lopez.



This message was sent using IMP, the Internet Messaging Program.

Re: AMD64 packages - Reflecting dynamic linking

[FRIGN]

On Thu, 01 Jan 2015 10:04:26 -0700
Theo de Raadt  wrote:

> Ah, another arrogance -- you came here to advertise.

Nope, if you read my first mail again, you'd see that I did not mention
our project once and only presented it to challenge your assumption that
I'm just some warrior presenting crude ideas.

> You will gain little security or safety by rewriting everything for a
> small and obscure userbase, without attacking the hard problems of
> coding and enabling all possible mitigations.

These words are very true. Even with arc4random() and given how long it
has been around (and given how _obvious_ its benefits are), people still
use PRNG's attempting to generate truly random data.

> Static binaries are not a valid mitigation.
> It sounds like you have no real word experience, because your userbase is
> nonexistant.

Maybe you are right. I must confess that I am an optimist and idealist
when it comes to software development and looking at most software,
mostly what I've seen in the last few years, you can't learn enough
that there are many ugly spots in this area.
You don't need a large userbase to see the issues even with a long-term
switch to static binaries (so I definitely know what you're talking
about) and that it is not a trivial thing.

However, as a long-term perspective, one might hope that software
development will actually take hardware-advancements in regard not by
crufting software with more complexity, but by actually optimizing the
foundation. You don't need to rewrite a lot to achieve that, same as
you didn't have to rewrite a lot to make srand() truly random in builds
that were non-deterministic.

But I see that this discussion is getting nowhere for good reasons on
both sides. So let's get back to coding.

Happy hacking!

Cheers

FRIGN

-- 
FRIGN 

Re: AMD64 packages - Reflecting dynamic linking

[Theo de Raadt]

> > And who are you, and what you have you done to test and then prove
> > your thesis?
> > Absolutely nothing, I must assume.
> 
> Your assumption is wrong. I am working with my colleagues from 2f30 on
> the "morpheus"-project[0] (including package-manager) and we have a set
> of static binary-packages[1] already ready for use.

Ah, another arrogance -- you came here to advertise.


You will gain little security or safety by rewriting everything for a
small and obscure userbase, without attacking the hard problems of
coding and enabling all possible mitigations.

Static binaries are not a valid mitigation.


It sounds like you have no real word experience, because your userbase is
nonexistant.

Re: AMD64 packages - Reflecting dynamic linking

[FRIGN]

On Thu, 01 Jan 2015 09:37:24 -0700
Theo de Raadt  wrote:

> And who are you, and what you have you done to test and then prove
> your thesis?
> Absolutely nothing, I must assume.

Your assumption is wrong. I am working with my colleagues from 2f30 on
the "morpheus"-project[0] (including package-manager) and we have a set
of static binary-packages[1] already ready for use.
 
> (BTW, your argument is weak and would be stronger if you tied it into
> the faked moonlandings).

I know you as a rude person and like your humour, but your response
contains no argument against the points I have given.
I'm not saying that in an arrogant way (maybe I'm getting this whole deal
completely wrong) and wanted to give some food for thought for the future.

The OpenBSD-security-focus paid off. It wasn't the fastest system 10 years
ago and isn't today, but when it made a difference in the past, security is
more important today than speed, given how rapidly hardware is developing.

I see the same issue here: How long do we really want to waste our time on
this cruft and develop libraries with the wrong concept in our heads when
dynamic linking is apparently becoming more and more irrelevant?

Cheers

FRIGN

[0]: http://morpheus.2f30.org/
[1]: http://morpheus.2f30.org/0.0/packages/x86_64/

-- 
FRIGN 

Re: AMD64 packages - Reflecting dynamic linking

[Theo de Raadt]

And who are you, and what you have you done to test and then prove
your thesis?

Absolutely nothing, I must assume.

(BTW, your argument is weak and would be stronger if you tied it into
the faked moonlandings).

> I may get a little off-topic here and object for this very important
> topic to be discussed in a separate thread some day, but come to
> think of it, the overhead induced with dynamic linking, symbol
> versioning and crazy workarounds to make the dynamic linker remotely
> safe nowadays completely destroy the once good reasons for dynamic
> libraries.
> Static linking eliminates all the issues involved with symbol versions,
> wrecking your system with a library update and I'd even go as far
> as saying that static binaries are more or less independent from
> distributions. Memory usage is also not a point any more, because we
> have shared tables nowadays and in many cases, statically linked
> programs need less RAM than dynamically linked ones.
> 
> So, what are the remaining arguments against static linking?
> I agree there are programs which do not run well if statically linked
> (the X-server for instance), but that's more or less a matter of design
> and can be worked around in most cases.
> 
> One specific point often raised is the argument, that if you have
> an update for a specific library (a security update for instance),
> you just need to recompile the library and all programs depending
> on the library will behave correctly.
> With static libraries on the other hand, you would have to recompile
> all binaries and superset-libraries depending on this library for
> the security fix to be effective.
> This point is increasingly losing significance due to the following
> reasons:
> 
> 1) hot-swapping a library for a security-fix implies that the ABI
> doesn't change, i.e. that the binaries on your system using this
> library can access the functions the way they have been told
> where they can find them.
> In many cases nowadays, bugs are fixed concurrently with version
> bumps (major & minor) which means that all binaries have to be
> manually updated and recompiled anyway.
> 
> 2) compiling is not expensive any more (in most cases).
> On my Gentoo-based system, it just takes 2 hours to recompile the
> entire operating system including all user-space applications.
> Moore's law will decrease this time over the years significantly.
> Imagine if it just took 5 minutes, would there still be a reason to
> have a hand-crafted dynamic linker to carefully dissect libraries
> and binaries, imposing a run-time loss and lots of
> security-considerations?
> I'm not talking about beasts like libreoffice, chromium and others.
> There are better alternatives around and if not, there will be in the
> future. For huge packages, it should be simple enough to design the
> package-manager in a way serving static binaries, and in case there is
> a library-fix, tell all clients to redownload the current version
> again. So the only real worry here is to have a clean build-
> environment on the build-servers (designed by experts) and not wasting
> hundreds of man-hours designing systems to cope with the dll-hell
> almost all Un*xes have become on the client-side.
> 
> Why is Linux/BSD not popular on the desktop? Because of fragmentation.
> And one reason for fragmentation is that you can't use Debian packages
> in Ubuntu, mostly because there are library incompatibilities.
> Other reasons are lack of good software, but that's just a matter of
> time. And if we can get more developers to work on useful stuff instead
> of having to worry about library-versioning, this goal could be reached
> in shorter time.
> 
> It may be a little far-fetched, but I'm sure it would be possible
> to have one package-manager for all distributions if there would just
> be the motivation to distribute statically linked binaries and not fuck
> things up with distribution-specific folder-structures.
> 
> 3) security
> Well, the issues with dynamic linking have been stated often enough[0]
> [1][2][3][4].
> As far as I understand, the initial motivation of the OpenBSD-project
> was to favor security over speed. It just puzzles me that issues like
> dynamic linking have not yet been discussed broadly or dealt with in
> the last few years given these obvious negative implications.
> 
> Please let me know what you think.
> 
> Cheers
> 
> FRIGN
> 
> [0]: http://www.catonmat.net/blog/ldd-arbitrary-code-execution/
> [1]: http://benpfaff.org/papers/asrandom.pdf
> [2]: 
> http://web.archive.org/web/20120509105723/http://teddziuba.com/2008/09/a-web-os-are-you-dense.html
> [3]: https://www.nth-dimension.org.uk/pub/BTL.pdf
> [4]: http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols
> 
> -- 
> FRIGN 

Re: AMD64 packages - Reflecting dynamic linking

[FRIGN]

On Fri, 12 Dec 2014 20:02:33 +0100
Ingo Schwarze  wrote:

> There are dragons.

> If this scares anybody, i'm not surprised; updating libraries is
> not a playground for newbies.

> That, actually, is *terrible* advice and almost guarantees a fiasco.
> If you edit shlib_version manually, you build a library containing
> code *incompatible* with what it's supposed to contain, so the end
> result will be that programs using that library will, at run time,
>  * crash,
>  * produce obviously wrong results,
>  * and/or silently produce results that are wrong in non-obvious ways.
> Some programs, by mere luck, may also work, if you are lucky,
> but it's hard to predict in advance which ones will and which 
> ones wont.

> To update a library, update all related source code - ideally,
> the whole source tree unless you know precisely what you are
> doing - to one consistent state, than compile from that state
> *without* manually screwing with shlib_version.  That's the whole
> point of library versioning!

I may get a little off-topic here and object for this very important
topic to be discussed in a separate thread some day, but come to
think of it, the overhead induced with dynamic linking, symbol
versioning and crazy workarounds to make the dynamic linker remotely
safe nowadays completely destroy the once good reasons for dynamic
libraries.
Static linking eliminates all the issues involved with symbol versions,
wrecking your system with a library update and I'd even go as far
as saying that static binaries are more or less independent from
distributions. Memory usage is also not a point any more, because we
have shared tables nowadays and in many cases, statically linked
programs need less RAM than dynamically linked ones.

So, what are the remaining arguments against static linking?
I agree there are programs which do not run well if statically linked
(the X-server for instance), but that's more or less a matter of design
and can be worked around in most cases.

One specific point often raised is the argument, that if you have
an update for a specific library (a security update for instance),
you just need to recompile the library and all programs depending
on the library will behave correctly.
With static libraries on the other hand, you would have to recompile
all binaries and superset-libraries depending on this library for
the security fix to be effective.
This point is increasingly losing significance due to the following
reasons:

1) hot-swapping a library for a security-fix implies that the ABI
doesn't change, i.e. that the binaries on your system using this
library can access the functions the way they have been told
where they can find them.
In many cases nowadays, bugs are fixed concurrently with version
bumps (major & minor) which means that all binaries have to be
manually updated and recompiled anyway.

2) compiling is not expensive any more (in most cases).
On my Gentoo-based system, it just takes 2 hours to recompile the
entire operating system including all user-space applications.
Moore's law will decrease this time over the years significantly.
Imagine if it just took 5 minutes, would there still be a reason to
have a hand-crafted dynamic linker to carefully dissect libraries
and binaries, imposing a run-time loss and lots of
security-considerations?
I'm not talking about beasts like libreoffice, chromium and others.
There are better alternatives around and if not, there will be in the
future. For huge packages, it should be simple enough to design the
package-manager in a way serving static binaries, and in case there is
a library-fix, tell all clients to redownload the current version
again. So the only real worry here is to have a clean build-
environment on the build-servers (designed by experts) and not wasting
hundreds of man-hours designing systems to cope with the dll-hell
almost all Un*xes have become on the client-side.

Why is Linux/BSD not popular on the desktop? Because of fragmentation.
And one reason for fragmentation is that you can't use Debian packages
in Ubuntu, mostly because there are library incompatibilities.
Other reasons are lack of good software, but that's just a matter of
time. And if we can get more developers to work on useful stuff instead
of having to worry about library-versioning, this goal could be reached
in shorter time.

It may be a little far-fetched, but I'm sure it would be possible
to have one package-manager for all distributions if there would just
be the motivation to distribute statically linked binaries and not fuck
things up with distribution-specific folder-structures.

3) security
Well, the issues with dynamic linking have been stated often enough[0]
[1][2][3][4].
As far as I understand, the initial motivation of the OpenBSD-project
was to favor security over speed. It just puzzles me that issues like
dynamic linking have

pf state key linking mismatch

[Michel Blais]

Hi,

I can't really find anything explaning these error except that some said 
that you never want it to happen and Henning writing that it could be 
ignore in some case. In my case, I think I should ignore it but would 
like to understand it just to be sure.


pf: state key linking mismatch! dir=OUT, if=em1, stored af=2, a0: 
0.0.0.0:53504, a1: 68.67.XXX.XXX:47406, proto=17, found af=2, a0: 
68.67.XXX.XXX:47406, a1: 10.8.0.1:53504, proto=17


68.67.XXX.XXX is inside my network and the're not any nat rules for this 
IP adress since it's a public one.


em1 is my internal if with ip 10.8.0.1. Proto 17 = udp

a0: 0.0.0.0:53504 ??? What could this IP address meen ? For sure, it's 
not a broadcast.


Which of those are src and dst ip address ?

My nat rules :
match on $ext_if  from 10.8.0.2   binat-to 64.119.XXX.XXX
match out on $ext_if inet from   nat-to   $ext_if

pfctl -t ipnat -Ts
   10.0.0.0/8
   96.XXX.XXX.0/20
   216.XXX.XXX.0/24
   216.XXX.XXX.0/24
   216.XXX.XXX.0/24
   216.XXX.XXX.0/24
   216.XXX.XXX.0/24

Those public IP address are only in the NAT rules because the should 
never goes out by this edge except in case big problem at our other edge 
that have some fibers in redondancy. It will be replace by BGP eventually.


Thanks

Michel

linking

[igor denisov]

The solution to the problem of linking radeon_drv.so and xorg.conf was
quite a simple thing as to remove radeonhd_drv.so radeonhd_drv.la,
start xorg -configure and that's all, no warnings anymore.
Regards.

Re: linking

[Nick Holland]

On 08/25/2011 12:56 PM, igor denisov wrote:

Hi there,

I am confused about ln.
I need to link /usr/X11R6/lib/modules/drivers/radeon_drv.so to
/etc/xorg.conf
and cannot understand how. May you help me?


no.
Whatever you are trying to accomplish, I think you are going about it 
wrong.  I presume this has to do with the other fragmentary and 
incomplete messages you have been spamming misc@ with (in the Monty 
Python defintion of spam, not the commercial email definition).


Let's start completely over.

What goal are you trying to accomplish?
How did you try to accomplish that goal?
What problem are you running into in the attempt to achieve that goal?
What did you do to encounter that problem?

and..tell us all about the hardware you are trying to accomplish this 
goal with...which is done by giving us the dmesg.


Plan on spending a good half-hour (or a LOT more!) putting all your 
facts and story together.  Spend MORE time asking your question 
carefully than you expect those of us who are providing you with free 
assistance to spend figuring out what you are trying to do.


Nick.

linking

[igor denisov]

Hi there,

I am confused about ln.
I need to link /usr/X11R6/lib/modules/drivers/radeon_drv.so to 
/etc/xorg.conf

and cannot understand how. May you help me?

--
igor denisov.

Re: pf: state key linking mismatch (?)

[Limaunion]

On 07/31/2011 07:13 AM, Henning Brauer wrote:

* Limaunion  [2011-07-17 02:26]:

hi all: I'm getting tons of messages like this one:

pf: state key linking mismatch! dir=OUT, if=vr1, stored af=2, a0:
83.237.186.131:51413, a1: 192.168.1.2:64768, proto=17, found af=2,
a0: 192.168.1.2:64768, a1: 181.110.135.229:51413, proto=17

The public 'a1' address (181.110.135.229) is repeated always but
does not much my real public interface address.

The rule is probably related with this line:

@41 pass in on vr0 inet proto tcp from any to (vr0:1) port = 64768
flags S/SA synproxy state (max 50, adaptive.start 30, adaptive.end
60) tag VR0_TAG rdr-to 192.168.1.2 port 64768

Can someone enlighten me what does this means?


executive summary? you can ignore it.

this is a check just before linking state keys together. in this case,
they must not be linked because something in the way changed things.
usually some kind of tunnel or encryption.
in a perfect world we'd find all these codepathes and add the calls to
pf_pkt_addr_changed(). we're not making much progress lately in
idetifying the few remaining ones tho :((



ok, thanks Henning for the clarification, now at least I know that this 
is not a mistake related with my rules.

Regards.

Re: pf: state key linking mismatch (?)

[Henning Brauer]

* Limaunion  [2011-07-17 02:26]:
> hi all: I'm getting tons of messages like this one:
> 
> pf: state key linking mismatch! dir=OUT, if=vr1, stored af=2, a0:
> 83.237.186.131:51413, a1: 192.168.1.2:64768, proto=17, found af=2,
> a0: 192.168.1.2:64768, a1: 181.110.135.229:51413, proto=17
> 
> The public 'a1' address (181.110.135.229) is repeated always but
> does not much my real public interface address.
> 
> The rule is probably related with this line:
> 
> @41 pass in on vr0 inet proto tcp from any to (vr0:1) port = 64768
> flags S/SA synproxy state (max 50, adaptive.start 30, adaptive.end
> 60) tag VR0_TAG rdr-to 192.168.1.2 port 64768
> 
> Can someone enlighten me what does this means?

executive summary? you can ignore it.

this is a check just before linking state keys together. in this case,
they must not be linked because something in the way changed things.
usually some kind of tunnel or encryption.
in a perfect world we'd find all these codepathes and add the calls to
pf_pkt_addr_changed(). we're not making much progress lately in
idetifying the few remaining ones tho :((

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

pf: state key linking mismatch (?)

[Limaunion]

hi all: I'm getting tons of messages like this one:

pf: state key linking mismatch! dir=OUT, if=vr1, stored af=2, a0: 
83.237.186.131:51413, a1: 192.168.1.2:64768, proto=17, found af=2, a0: 
192.168.1.2:64768, a1: 181.110.135.229:51413, proto=17


The public 'a1' address (181.110.135.229) is repeated always but does 
not much my real public interface address.


The rule is probably related with this line:

@41 pass in on vr0 inet proto tcp from any to (vr0:1) port = 64768 flags 
S/SA synproxy state (max 50, adaptive.start 30, adaptive.end 60) tag 
VR0_TAG rdr-to 192.168.1.2 port 64768


Can someone enlighten me what does this means?
TIA!

Re: fmt_scaled, linking problem

[Gilles Chehade]

link to libutil :-)

cc -o plop plop.c -lutil

Gilles

On Sat, Oct 23, 2010 at 09:30:47PM +0200, Stefan Johansson wrote:
> Hello!
> 
> I am wondering if anyone else has seen this problem in the latest current \
> snapshots.
> I have a C-program that uses the fmt_scaled function from .
> This program compiled and linked fine a couple of weeks ago but now I get the
> \
> following error:
> 
> /tmp//ccUmAX34.o(.text+0x34): In function `main':
> : undefined reference to `fmt_scaled'
> collect2: ld returned 1 exit status
> 
> 
> It will compile if I run `gcc -c` without linking.
> Just to demonstrate i tried this little piece of code:
> 
> #include 
> #include 
> #include 
> 
> int main(int argc, char *argv[]) {
>   char buf[FMT_SCALED_STRSIZE];
>long long ninput = 10483892;
>if (fmt_scaled(ninput, buf) == 0)
>   printf("%lld -> %s\n", ninput, buf);
>   else
>fprintf(stderr, "fmt scaled failed (errno %d)", errno);
> }
> 
> Any hints would be very much appreciated.
> 
> Here is my dmesg:
> OpenBSD 4.8-current (GENERIC.MP) #479: Thu Oct 21 00:10:43 MDT 2010
>dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> cpu0: Pentium(R) Dual-Core CPU E5400 @ 2.70GHz ("GenuineIntel" 686-class) 2.71
> GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,CX1
> 6,xTPR,PDCM,XSAVE
> real mem  = 1071947776 (1022MB)
> avail mem = 1044389888 (996MB)
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 05/15/09, BIOS32 rev. 0 @ 0xfac90,
> SMBIOS rev. 2.5 @ 0x3ff9c000 (46 entries)
> bios0: vendor Dell Inc. version "1.4.3" date 05/15/2009
> bios0: Dell Inc. PowerEdge R200
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP APIC SPCR HPET MCFG WD__ SLIC ERST HEST BERT EINJ SSDT
> SSDT SSDT
> acpi0: wakeup devices PCI0(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: apic clock running at 200MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Pentium(R) Dual-Core CPU E5400 @ 2.70GHz ("GenuineIntel" 686-class) 2.71
> GHz
> cpu1:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,CX1
> 6,xTPR,PDCM,XSAVE
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> ioapic0: misconfigured as apic 0, remapped to apid 2
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (PEX1)
> acpiprt2 at acpi0: bus 2 (SBE0)
> acpiprt3 at acpi0: bus 3 (SBE4)
> acpiprt4 at acpi0: bus 4 (SBE5)
> acpiprt5 at acpi0: bus 5 (COMP)
> acpicpu0 at acpi0: PSS
> acpicpu1 at acpi0: PSS
> bios0: ROM list: 0xc/0x9000 0xc9000/0x1000 0xca000/0x1800 0xcb800/0x5c00
> 0xec000/0x4000!
> ipmi at mainbus0 not configured
> cpu0: Enhanced SpeedStep 2701 MHz: speeds: 2700, 2400, 2200, 2000, 1800, 1600,
> 1400, 1200 MHz
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 3200/3210 Host" rev 0x01
> ppb0 at pci0 dev 1 function 0 "Intel 3200/3210 PCIE" rev 0x01: apic 2 int 16
> (irq 15)
> pci1 at ppb0 bus 1
> mpi0 at pci1 dev 0 function 0 "Symbios Logic SAS1068E" rev 0x08: apic 2 int 16
> (irq 15)
> scsibus0 at mpi0: 112 targets
> sd0 at scsibus0 targ 0 lun 0:  SCSI3 0/direct fixed
> sd0: 152064MB, 512 bytes/sec, 311427072 sec total
> sd1 at scsibus0 targ 4 lun 0:  SCSI3 0/direct
> fixed
> sd1: 1430799MB, 512 bytes/sec, 2930277168 sec total
> sd2 at scsibus0 targ 6 lun 0:  SCSI3 0/direct fixed
> sd2: 1430799MB, 512 bytes/sec, 2930277168 sec total
> sd3 at scsibus0 targ 7 lun 0:  SCSI3 0/direct
> fixed
> sd3: 953869MB, 512 bytes/sec, 1953525168 sec total
> ppb1 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: apic 2 int 16
> (irq 15)
> pci2 at ppb1 bus 2
> ppb2 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02
> pci3 at ppb2 bus 3
> bge0 at pci3 dev 0 function 0 "Broadcom BCM5721" rev 0x21, BCM5750 C1
> (0x4201): apic 2 int 16 (irq 15), address a4:ba:db:df:ae:2a
> brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
> ppb3 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02
> pci4 at ppb3 bus 4
> bge1 at pci4 dev 0 function 0 "Broadcom BCM5721" rev 0x21, BCM5750 C1
> (0x4201): apic 2 int 17 (irq 14), address a4:ba:db:df:ae:2b
> brgphy1 at bge1 phy 1: BCM5750 10/100/1000b

fmt_scaled, linking problem

[Stefan Johansson]

Hello!

I am wondering if anyone else has seen this problem in the latest current \
snapshots.
I have a C-program that uses the fmt_scaled function from .
This program compiled and linked fine a couple of weeks ago but now I get the
\
following error:

/tmp//ccUmAX34.o(.text+0x34): In function `main':
: undefined reference to `fmt_scaled'
collect2: ld returned 1 exit status


It will compile if I run `gcc -c` without linking.
Just to demonstrate i tried this little piece of code:

#include 
#include 
#include 

int main(int argc, char *argv[]) {
char buf[FMT_SCALED_STRSIZE];
   long long ninput = 10483892;
   if (fmt_scaled(ninput, buf) == 0)
printf("%lld -> %s\n", ninput, buf);
else
   fprintf(stderr, "fmt scaled failed (errno %d)", errno);
}

Any hints would be very much appreciated.

Here is my dmesg:
OpenBSD 4.8-current (GENERIC.MP) #479: Thu Oct 21 00:10:43 MDT 2010
   dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Pentium(R) Dual-Core CPU E5400 @ 2.70GHz ("GenuineIntel" 686-class) 2.71
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,CX1
6,xTPR,PDCM,XSAVE
real mem  = 1071947776 (1022MB)
avail mem = 1044389888 (996MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 05/15/09, BIOS32 rev. 0 @ 0xfac90,
SMBIOS rev. 2.5 @ 0x3ff9c000 (46 entries)
bios0: vendor Dell Inc. version "1.4.3" date 05/15/2009
bios0: Dell Inc. PowerEdge R200
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET MCFG WD__ SLIC ERST HEST BERT EINJ SSDT
SSDT SSDT
acpi0: wakeup devices PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Pentium(R) Dual-Core CPU E5400 @ 2.70GHz ("GenuineIntel" 686-class) 2.71
GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,CX1
6,xTPR,PDCM,XSAVE
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEX1)
acpiprt2 at acpi0: bus 2 (SBE0)
acpiprt3 at acpi0: bus 3 (SBE4)
acpiprt4 at acpi0: bus 4 (SBE5)
acpiprt5 at acpi0: bus 5 (COMP)
acpicpu0 at acpi0: PSS
acpicpu1 at acpi0: PSS
bios0: ROM list: 0xc/0x9000 0xc9000/0x1000 0xca000/0x1800 0xcb800/0x5c00
0xec000/0x4000!
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 2701 MHz: speeds: 2700, 2400, 2200, 2000, 1800, 1600,
1400, 1200 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 3200/3210 Host" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel 3200/3210 PCIE" rev 0x01: apic 2 int 16
(irq 15)
pci1 at ppb0 bus 1
mpi0 at pci1 dev 0 function 0 "Symbios Logic SAS1068E" rev 0x08: apic 2 int 16
(irq 15)
scsibus0 at mpi0: 112 targets
sd0 at scsibus0 targ 0 lun 0:  SCSI3 0/direct fixed
sd0: 152064MB, 512 bytes/sec, 311427072 sec total
sd1 at scsibus0 targ 4 lun 0:  SCSI3 0/direct
fixed
sd1: 1430799MB, 512 bytes/sec, 2930277168 sec total
sd2 at scsibus0 targ 6 lun 0:  SCSI3 0/direct fixed
sd2: 1430799MB, 512 bytes/sec, 2930277168 sec total
sd3 at scsibus0 targ 7 lun 0:  SCSI3 0/direct
fixed
sd3: 953869MB, 512 bytes/sec, 1953525168 sec total
ppb1 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: apic 2 int 16
(irq 15)
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02
pci3 at ppb2 bus 3
bge0 at pci3 dev 0 function 0 "Broadcom BCM5721" rev 0x21, BCM5750 C1
(0x4201): apic 2 int 16 (irq 15), address a4:ba:db:df:ae:2a
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
ppb3 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02
pci4 at ppb3 bus 4
bge1 at pci4 dev 0 function 0 "Broadcom BCM5721" rev 0x21, BCM5750 C1
(0x4201): apic 2 int 17 (irq 14), address a4:ba:db:df:ae:2b
brgphy1 at bge1 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
uhci0 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 2 int 21
(irq 11)
uhci1 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 2 int 20
(irq 10)
uhci2 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x02: apic 2 int 21
(irq 11)
ehci0 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x02: apic 2 int 21
(irq 11)
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb4 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x92
pci5 at ppb4 bus 5
vga1 at pci5 dev 5 function 0 "ATI ES1000" rev 0x02
wsdisplay0 at vga1 

Re: openbsd 3.9 umass not linking to a sd

[Swa Frantzen]

> it doesn't want to play nice with USB drives.

Ok: I finally found the problem: my test disks all were a portable  
ones -powered from the USB bus-.

Cause that's what I had around the house.
I know the USB port needs to deliver enough juice to make it work, and  
I had taken that into
account: I had plugged in the power only connector on another USB  
port, getting more power

if needed.
But apparently that's still not enough power from that server's  
motherboard. Only after plugging it
in on a standalone power supply the drive seems to spin up. (I had not  
heard it trying to spin
up and fail (the server makes way too much noise to ever hear the  
quite silent drive).


So yeah: 3.9 does support it and I can now order some external 1Tbyte  
drives to use as backup

medium, they now are cheaper than tape anyway.

Next step will be to figure out how to get dump to fill disks like it  
can fill tapes, or something
somewhat similar. But at least I now have a path out of that corner I  
found myself in.


Lesson:
- don't assume the drive gets enough power, not even if you plug it in  
on 2 USB ports


Wishlist:
Error messages telling you something (if that's possible at all to  
start with).

"I'm giving it all she's got Jim, need more dilithium crystals"

Re: openbsd 3.9 umass not linking to a sd

[Swa Frantzen]

That would void the warranties on the external disks I'm afraid.

Is there no way to get this working in a stock 3.9 ?
And would it work in 4.6 ?

SWA

On 22 Oct 2009, at 20:30, Kenneth R Westerback wrote:


On Thu, Oct 22, 2009 at 02:48:09PM +0200, Laurens Vets wrote:

Hey Swa,


I seem to have painted myself in a corner somehow.
I can't upgrade without getting the data off of the system and it
doesn't want to play nice with USB drives.





I could try to look at old school BSD stuff and think about
building a new kernel, but the amount
of "don't do that" seems to be high, so is there a better path ?  
Where ?


I know it's an old release, trying to fix that, but in order to
get there ...


And there's no way to temporarily add an internal disk to an onboard
IDE  port or something?

-Laurens



Just plug the temp disk in to the IDE port (hoping it doesn't appear
earlier than your existing disk in the probe or boot process!),
then do the fdisk/disklabel/newfs/mount dance, copy your data off
to the new filesystem, and it should be accessable to the new 4.6
install.

 Ken

Re: openbsd 3.9 umass not linking to a sd

[Stuart Henderson]

You can probably boot an install CD and go to the shell.
Assuming you can then see sd* at umass (which is fairly likely),
you should be able to mount/newfs as necessary, and copy the
data from the ami (pax/tar/cp/dd are available).

Or if you have another system running that you can save a
backup onto you can easily run dump piped over ssh.


On 2009-10-22, Swa Frantzen  wrote:
> I seem to have painted myself in a corner somehow.
> I can't upgrade without getting the data off of the system and it  
> doesn't want to play nice with USB drives.
>
> The system:
> - amd64
> - generic.mp kernel
> - OpenBSD 3.9
> - contains an hardware raid card (AMI) creating 2 "virtual" sd drives:  
> sd0 and sd1
> Cannot touch them really, they contain precious data.
>
> When I hook up an USB drive, I get  :
>
> umass0 at uhub1 port 1 configuration 1 interface 0
> umass0: LaCie LaCie HardDrive USB, rev 2.00/0.00, addr 2
> umass0: using SCSI over Bulk-Only
> scsibus4 at umass0: 2 targets
>
> but no sd drive is assigned. (nor do any of those in existence aside  
> of sd0 and sd1 from the raid controller do anything).
>
> There are NO other USB devices used on that system, not even a keyboard.
>
> The system is showing age and I'd like to upgrade it, but without  
> having an offline copy of the data that's not going to happen.
> And the LTO-3 tape drive is flacky at best, so I'd like to by some  
> really big external drives as backup (the AMI provides about 3Tbyte of  
> space)
>
> So I'd need to know how to trigger the kernel to let me do something  
> with that umass0 by "linking" it to a sd2 or so.
>
> Might there be too many scsibusses for the generic kernel?
>
> scsibus0: atapi CDROM
> scsibus1: adaptec controller
> scsibus2: AMI
> scsibus3: AMI
> scsibus4: USB
>
> I could try to look at old school BSD stuff and think about building a  
> new kernel, but the amount
> of "don't do that" seems to be high, so is there a better path ? Where ?
>
> I know it's an old release, trying to fix that, but in order to get  
> there ...
>
> SWA
>
>
> # dmesg
> OpenBSD 3.9 (GENERIC.MP) #736: Thu Mar  2 04:02:03 MST 2006
>  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ 
> GENERIC.MP
> real mem = 2146410496 (2096104K)
> avail mem = 1835237376 (1792224K)
> using 22937 buffers containing 214847488 bytes (209812K) of memory
> mainbus0 (root)
> mainbus0: Intel MP Specification (Version 1.4) (AMD  HAMMER  )
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Opteron(tm) Processor 246, 2004.80 MHz
> cpu0:  
> FPU 
> ,VME 
> ,DE 
> ,PSE 
> ,TSC 
> ,MSR 
> ,PAE 
> ,MCE 
> ,CX8 
> ,APIC 
> ,SEP 
> ,MTRR 
> ,PGE 
> ,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG, 
> 3DNOW2,3DNOW
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB  
> 64b/line 16-way L2 cache
> cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully  
> associative
> cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully  
> associative
> cpu0: apic clock running at 200MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD Opteron(tm) Processor 246, 2004.55 MHz
> cpu1:  
> FPU 
> ,VME 
> ,DE 
> ,PSE 
> ,TSC 
> ,MSR 
> ,PAE 
> ,MCE 
> ,CX8 
> ,APIC 
> ,SEP 
> ,MTRR 
> ,PGE 
> ,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG, 
> 3DNOW2,3DNOW
> cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB  
> 64b/line 16-way L2 cache
> cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully  
> associative
> cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully  
> associative
> mpbios: bus 0 is type PCI
> mpbios: bus 1 is type PCI
> mpbios: bus 2 is type PCI
> mpbios: bus 3 is type PCI
> mpbios: bus 4 is type PCI
> mpbios: bus 5 is type ISA
> ioapic0 at mainbus0 apid 2: pa 0x8373bf24, version 11, 24 pins
> ioapic1 at mainbus0 apid 3: pa 0x8373be24, version 11, 4 pins
> ioapic2 at mainbus0 apid 4: pa 0x8373bd24, version 11, 4 pins
> pci0 at mainbus0 bus 0: configuration mode 1
> ppb0 at pci0 dev 6 function 0 "AMD 8111 PCI-PCI" rev 0x07
> pci1 at ppb0 bus 1
> ohci0 at pci1 dev 0 function 0 "AMD 8111 USB" rev 0x0b: apic 2 int 19  
> (irq 11), version 1.0, legacy support
> usb0 at ohci0: USB revision 1.0
> uhub0 at usb0
> uhub0: AMD OHCI root hub, rev 1.00/1.00, addr 1
> uhub0: 3 ports with 3 removable, self powered
> ohci1 at pci1 dev 0 function 1 "AMD 8111 USB" rev 0x0b: apic 2 int 19  
> (irq 11), version 1.0, legacy support
> usb1 

Re: openbsd 3.9 umass not linking to a sd

[Kenneth R Westerback]

On Thu, Oct 22, 2009 at 02:48:09PM +0200, Laurens Vets wrote:
> Hey Swa,
> 
> >I seem to have painted myself in a corner somehow.
> >I can't upgrade without getting the data off of the system and it
> >doesn't want to play nice with USB drives.
> >
> 
> >
> >I could try to look at old school BSD stuff and think about
> >building a new kernel, but the amount
> >of "don't do that" seems to be high, so is there a better path ? Where ?
> >
> >I know it's an old release, trying to fix that, but in order to
> >get there ...
> 
> And there's no way to temporarily add an internal disk to an onboard
> IDE  port or something?
> 
> -Laurens
> 

Just plug the temp disk in to the IDE port (hoping it doesn't appear
earlier than your existing disk in the probe or boot process!),
then do the fdisk/disklabel/newfs/mount dance, copy your data off
to the new filesystem, and it should be accessable to the new 4.6
install.

 Ken

Re: openbsd 3.9 umass not linking to a sd

[Mauro Rezzonico]

Swa Frantzen wrote:
I can't upgrade without getting the data off of the system and it 
doesn't want to play nice with USB drives.


Use the network, Swa... ;)

dump/rsync/rcp/sftp/ftp-put/nfs/wathever over a network link to a 
different machine, maybe one that supports your USB disk...

It's not SO slow and, besides, does anybody have better ideas?

P.S.: I think you can do an SFTP remote mount over an SSH port in MAC OS 
X ('X-Mailer: Apple Mail (2.936)')...


--
Mauro Rezzonico , Como, Italia
"Maybe this world is another planet's hell" - H.Huxley

Re: openbsd 3.9 umass not linking to a sd

[Laurens Vets]

Hey Swa,


I seem to have painted myself in a corner somehow.
I can't upgrade without getting the data off of the system and it 
doesn't want to play nice with USB drives.






I could try to look at old school BSD stuff and think about building a 
new kernel, but the amount

of "don't do that" seems to be high, so is there a better path ? Where ?

I know it's an old release, trying to fix that, but in order to get 
there ...


And there's no way to temporarily add an internal disk to an onboard IDE 
 port or something?


-Laurens

openbsd 3.9 umass not linking to a sd

[Swa Frantzen]

I seem to have painted myself in a corner somehow.
I can't upgrade without getting the data off of the system and it  
doesn't want to play nice with USB drives.


The system:
- amd64
- generic.mp kernel
- OpenBSD 3.9
- contains an hardware raid card (AMI) creating 2 "virtual" sd drives:  
sd0 and sd1

Cannot touch them really, they contain precious data.

When I hook up an USB drive, I get  :

umass0 at uhub1 port 1 configuration 1 interface 0
umass0: LaCie LaCie HardDrive USB, rev 2.00/0.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus4 at umass0: 2 targets

but no sd drive is assigned. (nor do any of those in existence aside  
of sd0 and sd1 from the raid controller do anything).


There are NO other USB devices used on that system, not even a keyboard.

The system is showing age and I'd like to upgrade it, but without  
having an offline copy of the data that's not going to happen.
And the LTO-3 tape drive is flacky at best, so I'd like to by some  
really big external drives as backup (the AMI provides about 3Tbyte of  
space)


So I'd need to know how to trigger the kernel to let me do something  
with that umass0 by "linking" it to a sd2 or so.


Might there be too many scsibusses for the generic kernel?

scsibus0: atapi CDROM
scsibus1: adaptec controller
scsibus2: AMI
scsibus3: AMI
scsibus4: USB

I could try to look at old school BSD stuff and think about building a  
new kernel, but the amount

of "don't do that" seems to be high, so is there a better path ? Where ?

I know it's an old release, trying to fix that, but in order to get  
there ...


SWA


# dmesg
OpenBSD 3.9 (GENERIC.MP) #736: Thu Mar  2 04:02:03 MST 2006
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ 
GENERIC.MP

real mem = 2146410496 (2096104K)
avail mem = 1835237376 (1792224K)
using 22937 buffers containing 214847488 bytes (209812K) of memory
mainbus0 (root)
mainbus0: Intel MP Specification (Version 1.4) (AMD  HAMMER  )
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Opteron(tm) Processor 246, 2004.80 MHz
cpu0:  
FPU 
,VME 
,DE 
,PSE 
,TSC 
,MSR 
,PAE 
,MCE 
,CX8 
,APIC 
,SEP 
,MTRR 
,PGE 
,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG, 
3DNOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB  
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully  
associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully  
associative

cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Opteron(tm) Processor 246, 2004.55 MHz
cpu1:  
FPU 
,VME 
,DE 
,PSE 
,TSC 
,MSR 
,PAE 
,MCE 
,CX8 
,APIC 
,SEP 
,MTRR 
,PGE 
,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG, 
3DNOW2,3DNOW
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB  
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully  
associative
cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully  
associative

mpbios: bus 0 is type PCI
mpbios: bus 1 is type PCI
mpbios: bus 2 is type PCI
mpbios: bus 3 is type PCI
mpbios: bus 4 is type PCI
mpbios: bus 5 is type ISA
ioapic0 at mainbus0 apid 2: pa 0x8373bf24, version 11, 24 pins
ioapic1 at mainbus0 apid 3: pa 0x8373be24, version 11, 4 pins
ioapic2 at mainbus0 apid 4: pa 0x8373bd24, version 11, 4 pins
pci0 at mainbus0 bus 0: configuration mode 1
ppb0 at pci0 dev 6 function 0 "AMD 8111 PCI-PCI" rev 0x07
pci1 at ppb0 bus 1
ohci0 at pci1 dev 0 function 0 "AMD 8111 USB" rev 0x0b: apic 2 int 19  
(irq 11), version 1.0, legacy support

usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: AMD OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
ohci1 at pci1 dev 0 function 1 "AMD 8111 USB" rev 0x0b: apic 2 int 19  
(irq 11), version 1.0, legacy support

usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: AMD OHCI root hub, rev 1.00/1.00, addr 1
uhub1: 3 ports with 3 removable, self powered
vga1 at pci1 dev 6 function 0 "ATI Rage XL" rev 0x27
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 7 function 0 "AMD AMD8111 LPC" rev 0x05
pciide0 at pci0 dev 7 function 1 "AMD 8111 IDE" rev 0x03: DMA, channel  
0 configured to compatibility, channel 1 configured to compatibility

pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: <_NEC, DVD_RW ND-3550A, 1.05> SCSI0 5/ 
cdrom removable

cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
amdpm0 at pci0 dev 7 function 3 "AMD 8111 Power" rev 0x05: rng active
iic0 at amdpm0
admcts0 at iic0 addr 0x2c
ppb1 at pci0 dev 10 function 0 "AMD 8131 PCIX" rev 0x12
pci2 at ppb1 bus 2
ahd0 a

PF: state key linking mismatch with -current

[Josh Grosse]

I've just updated -current, and am a few days beyond henning@'s huge PF
change.  

I'm getting state mismatch warnings from the kernel. I do not understand 
the entries, so am not sure what to correct, if anything, in my new version 
of the rule.

-

The rule used to be:

rdr pass log on $external_nic proto {tcp udp} from any to any port x \
-> 192.168.1.42 port x

The rule now is:

pass in log quick on $external_nic proto {tcp udp} from any to any port x \
rdr-to 192.168.1.42 port x

-

Here are two example warning messages.  In each warning message, the 
first "a0" IP address is different from the second "a0" IP address, which 
matches the second "a1" address.  There are multiple valid states in the
state table, so not every state produces these messages:

-

pf: state key linking mismatch! dir=OUT, if=dc0, stored af=2, 
a0: a.b.c.d:39944, a1: 192.168.1.42:x, proto=17, 
found af=2, a0: e.f.g.h:65519, a1: e.f.g.h:48042, proto=17.

pf: state key linking mismatch! dir=OUT, if=dc0, stored af=2, 
a0: i.j.k.l:61418, a1: 192.168.1.42:x, proto=17, 
found af=2, a0: m.n.o.p:65519, a1: m.n.o.p:48042, proto=17.

-

Any suggestions would be greatly appreciated.  Thanks!

MULTILINGUAL DICTIONARY linking examples without leaving your web pages

[Translation Experts]

Dear Sir/Madam,

We have now upgraded our MULTILINGUAL DICTIONARY linking examples so that your 
users will no longer leave your web pages.

For more information, please go to:

http://www.tranexp.com/intertran/linking.cgi?31

We will be very happy to answer any queries you might have.

Best regards,

Translation Experts

Re: state key linking mismatch w/GRE, since 4.5

[Pascal Lalonde]

On Fri, Jun 12, 2009 at 05:56:43AM +0200, Henning Brauer wrote:
> * Pascal Lalonde  [2009-06-12 00:28]:
> > Jun 11 18:08:19 celeborn /bsd: pf: state key linking mismatch! dir=OUT,
> > if=bge0, stored af=2, a0: 10.136.192.199:30285, a1: 10.216.8.1:22,
> > proto=6, found af=2, a0: AAA.AAA.AAA.AAA, a1: BBB.BBB.BBB.BBB, proto=47.
> > Jun 11 18:08:21 celeborn /bsd: pf: state key linking mismatch! dir=OUT,
> > if=bge0, stored af=2, a0: 10.136.248.119:42137, a1: 10.137.0.130:993,
> > proto=6, found af=2, a0: AAA.AAA.AAA.AAA, a1: BBB.BBB.BBB.BBB, proto=47.
> 
> fixed in -current and no need to worry really

Small followup on this, for people who would happen to run in the same
problem.

We were just bitten by this issue. With our smaller VPN gateways (<10
flows with ESP/GRE), the extra logging didn't cause any issues. But once
we upgraded our main VPN endpoint (roughly 176 flows) to 4.5, seems it
didn't like the amount of printf()'s generated; the load would make it
unusuable, causing CARP flapping, with a very high (>80%) interrupt%.
Fortunately we still had our other node in 4.4 to fallback to.

I can confirm that on our test setup with a -current kernel, those messages
don't show up anymore.

In the meantime, we applied the following to let us control whether we
wish to see those warnings or not:


--- sys/net/pf.c.orig   Tue Jun 30 18:13:34 2009
+++ sys/net/pf.cTue Jun 30 18:44:00 2009
@@ -860,19 +860,22 @@
return (0);
else {
/* mismatch. must not happen. */
-   printf("pf: state key linking mismatch! dir=%s, "
-   "if=%s, stored af=%u, a0: ",
-   dir == PF_OUT ? "OUT" : "IN", kif->pfik_name, a->af);
-   pf_print_host(&a->addr[0], a->port[0], a->af);
-   printf(", a1: ");
-   pf_print_host(&a->addr[1], a->port[1], a->af);
-   printf(", proto=%u", a->proto);
-   printf(", found af=%u, a0: ", b->af);
-   pf_print_host(&b->addr[0], b->port[0], b->af);
-   printf(", a1: ");
-   pf_print_host(&b->addr[1], b->port[1], b->af);
-   printf(", proto=%u", b->proto);
-   printf(".\n");
+   if (pf_status.debug >= PF_DEBUG_MISC) {
+   printf("pf: state key linking mismatch! dir=%s, "
+   "if=%s, stored af=%u, a0: ",
+   dir == PF_OUT ? "OUT" : "IN", kif->pfik_name,
+   a->af);
+   pf_print_host(&a->addr[0], a->port[0], a->af);
+   printf(", a1: ");
+   pf_print_host(&a->addr[1], a->port[1], a->af);
+   printf(", proto=%u", a->proto);
+   printf(", found af=%u, a0: ", b->af);
+   pf_print_host(&b->addr[0], b->port[0], b->af);
+   printf(", a1: ");
+   pf_print_host(&b->addr[1], b->port[1], b->af);
+   printf(", proto=%u", b->proto);
+   printf(".\n");
+   }
return (-1);
}
 }


-- 
Pascal

Re: state key linking mismatch w/GRE, since 4.5

[Pascal Lalonde]

On Fri, Jun 12, 2009 at 05:56:43AM +0200, Henning Brauer wrote:
> * Pascal Lalonde  [2009-06-12 00:28]:
> > Jun 11 18:08:19 celeborn /bsd: pf: state key linking mismatch! dir=OUT,
> > if=bge0, stored af=2, a0: 10.136.192.199:30285, a1: 10.216.8.1:22,
> > proto=6, found af=2, a0: AAA.AAA.AAA.AAA, a1: BBB.BBB.BBB.BBB, proto=47.
> > Jun 11 18:08:21 celeborn /bsd: pf: state key linking mismatch! dir=OUT,
> > if=bge0, stored af=2, a0: 10.136.248.119:42137, a1: 10.137.0.130:993,
> > proto=6, found af=2, a0: AAA.AAA.AAA.AAA, a1: BBB.BBB.BBB.BBB, proto=47.
> 
> fixed in -current and no need to worry really

Good to hear!

Many thanks,
-- 
Pascal

Re: state key linking mismatch w/GRE, since 4.5

[Henning Brauer]

* Pascal Lalonde  [2009-06-12 00:28]:
> Jun 11 18:08:19 celeborn /bsd: pf: state key linking mismatch! dir=OUT,
> if=bge0, stored af=2, a0: 10.136.192.199:30285, a1: 10.216.8.1:22,
> proto=6, found af=2, a0: AAA.AAA.AAA.AAA, a1: BBB.BBB.BBB.BBB, proto=47.
> Jun 11 18:08:21 celeborn /bsd: pf: state key linking mismatch! dir=OUT,
> if=bge0, stored af=2, a0: 10.136.248.119:42137, a1: 10.137.0.130:993,
> proto=6, found af=2, a0: AAA.AAA.AAA.AAA, a1: BBB.BBB.BBB.BBB, proto=47.

fixed in -current and no need to worry really

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

state key linking mismatch w/GRE, since 4.5

[Pascal Lalonde]

Hello,

recently we upgraded some of our firewalls from OpenBSD 4.4 to 4.5.
Since then, we've been getting loads of the following message
(external addresses substitued with AAA's and BBB's):

Jun 11 18:08:19 celeborn /bsd: pf: state key linking mismatch! dir=OUT,
if=bge0, stored af=2, a0: 10.136.192.199:30285, a1: 10.216.8.1:22,
proto=6, found af=2, a0: AAA.AAA.AAA.AAA, a1: BBB.BBB.BBB.BBB, proto=47.
Jun 11 18:08:21 celeborn /bsd: pf: state key linking mismatch! dir=OUT,
if=bge0, stored af=2, a0: 10.136.248.119:42137, a1: 10.137.0.130:993,
proto=6, found af=2, a0: AAA.AAA.AAA.AAA, a1: BBB.BBB.BBB.BBB, proto=47.


Relevant states, taken right after the errors showed up in syslog:

all gre BBB.BBB.BBB.BBB <- AAA.AAA.AAA.AAA   MULTIPLE:MULTIPLE
all tcp 10.216.8.1:22 <- 10.136.192.199:30285 ESTABLISHED:ESTABLISHED
all tcp 10.136.192.199:30285 -> 10.216.8.1:22 ESTABLISHED:ESTABLISHED
all tcp 10.137.0.130:993 <- 10.136.248.119:42137 FIN_WAIT_2:FIN_WAIT_2
all tcp 10.136.248.119:42137 -> 10.137.0.130:993 FIN_WAIT_2:FIN_WAIT_2

gre25: flags=9011 mtu 1476
description: TUNNELING-10/8
priority: 0
groups: gre
physical address inet BBB.BBB.BBB.BBB --> AAA.AAA.AAA.AAA
inet6 fe80::204:23ff:feb1:73c4%gre25 ->  prefixlen 64 scopeid 0x12
inet 192.168.253.136 --> 192.168.136.253 netmask 0x

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
defaultBBB.BBB.BBB.CCCUGS4  1317018 - 8 bge0
10/8   192.168.136.253UGS0   769241 - 8 gre25
10.136.248/21  link#4 UC140 - 4 em3
BBB.BBB.BBB.0/27   link#9 UC110 - 4 bge0
...


Status: Enabled for 0 days 02:24:21   Debug: Urgent

State Table  Total Rate
  current entries 6281   
  searches14179937 1637.2/s
  inserts   586841   67.8/s
  removals  580560   67.0/s
Counters
  match 498717   57.6/s
  bad-offset 00.0/s
  fragment   00.0/s
  short  00.0/s
  normalize  00.0/s
  memory 00.0/s
  bad-timestamp  00.0/s
  congestion 00.0/s
  ip-option  00.0/s
  proto-cksum00.0/s
  state-mismatch280.0/s
  state-insert   50.0/s
  state-limit00.0/s
  src-limit  00.0/s
  synproxy   00.0/s


This is happening only on firewalls where we use GRE tunnels.

I guess that rev. 1.618 of pf.c, which was added in 4.5, is causing
those messages to appear. But we're not experimenting any network
problems despite the errors.

The ruleset being a bit lengthy, I left it out, but can send it
on demand.

Is there need to worry about those errors? 

Thanks,
-- 
Pascal

Re: pf state key linking mismatch

[Vadim Zhukov]

On 24 March 2009 G. 20:59:05 Stuart Henderson wrote:
> On 2009-03-24, Vadim Zhukov  wrote:
> > Hello all.
> >
> > As far as I remember, error message "pf: state key linking mismatch"
> > is not something anyone want to see on his console. For me it means
> > now that at some time machine will freeze up. Last tested kernel is
> > GENERIC one from the fresh snapshot (March, 23).
> >
> > Machine is (still) test proxy with 3 NICs: 2 two-port Intel gigabit
> > cards and internal BroadCom one, see dmesg below for details. One
> > NIC connects via its ports to different provider uplinks, and other
> > NICs are connected to LAN(s). More details may be found in PR 6095.
> >
> > A few minutes ago machine freezed, being stopped in
> > pf_icmp_mapping(). Keyboard did not work, and as far as I discovered
> > it fails to work in UKC, but that's totally different case I do not
> > bother much: there is SSH. So bad news are that I do not have "ps"
> > and "trace" output, sorry... There is no serial console either. :(
> > There is photo, though: http://77.108.65.40/dnl/P1030052.jpg
>
> So it should be short enough to re-type, yes? That will be easier than
> have whoever is interested in looking at this try and view your photo
> and find the URL isn't accessible.

Oops... I simply sent file over scp and didn't checked that KMail
extracted it (photographer is my co-worker, he sent photo attached in
private email) to /tmp with mode 0400... Sorry to all tried and
failed. :( Fixed now. And no, it was not short enough, until
skipping "linking mismatch" messages. But here it is without them:

kernel: page fault trap, code=0
Stopped at  pf_icmp_mapping+0x38:   movzwl  0x4(%rax),%eax
ddb{0}>

> Can you try a different type of keyboard though (PS/2 vs USB, or maybe
> even just change keyboard emulation settings in the BIOS)), or try and
> arrange serial console in case it happens again? it might be useful
> to get that trace.

As far as I remember, USB keyboards are useless in ddb(4) - am I wrong?
Of course, I tried different PS/2 keyboards, that worked fine on another
machines - just fail. There were other issues with keyboard
(controller), even during install, but I was too busy to worry about it.

Yes, I know that serial console should be very useful, but current
situation in my company do not give me opportunity to order one for
minimum next two months. :(

"pf: state key linking mismatch" message is very easy reproducible for
me, though: not directly ("touch that and it will happen"), but often
enough ("it'll eventually happen in a minute, just open and close some
connections").

--
  Best wishes,
Vadim Zhukov

Re: pf state key linking mismatch

[Stuart Henderson]

On 2009-03-24, Vadim Zhukov  wrote:
> Hello all.
>
> As far as I remember, error message "pf: state key linking mismatch" is 
> not something anyone want to see on his console. For me it means now 
> that at some time machine will freeze up. Last tested kernel is GENERIC 
> one from the fresh snapshot (March, 23).
>
> Machine is (still) test proxy with 3 NICs: 2 two-port Intel gigabit cards 
> and internal BroadCom one, see dmesg below for details. One NIC connects 
> via its ports to different provider uplinks, and other NICs are 
> connected to LAN(s). More details may be found in PR 6095.
>
> A few minutes ago machine freezed, being stopped in pf_icmp_mapping(). 
> Keyboard did not work, and as far as I discovered it fails to work in 
> UKC, but that's totally different case I do not bother much: there is 
> SSH. So bad news are that I do not have "ps" and "trace" output, 
> sorry... There is no serial console either. :( There is photo, though: 
> http://77.108.65.40/dnl/P1030052.jpg

So it should be short enough to re-type, yes? That will be easier than
have whoever is interested in looking at this try and view your photo
and find the URL isn't accessible.

Can you try a different type of keyboard though (PS/2 vs USB, or maybe
even just change keyboard emulation settings in the BIOS)), or try and
arrange serial console in case it happens again? it might be useful
to get that trace.

Re: Odd linking message (please relink your binary)

[Philip Guenther]

On Mon, Jul 28, 2008 at 11:22 AM, Edd Barrett <[EMAIL PROTECTED]> wrote:
> I have this strange link message for xetex (Im building binaries for the
> TL DVD, its nothing to do with the port).
>
> Take a look at this:
> http://tug.org/pipermail/tlbuild/2008q3/000310.html
>
> Does anyone have any clue what is happening here?

Looks like it still got linked with a static libfreetype2: see how ldd
shows the shared libfreetype2 as having a reference count of just 1?
Since libfontconfig has a reference to libfreetype2, that means the
base executable _doesn't_.  Since ld.so is complaining about symbol
size changes, the executable must have been linked with a static
version of libfreetype2 that's not compatible with the system one.
Check the log from building xetex to see whether it shows it doing
that or otherwise not liking the system one (despite you passing it
options telling it to use it).


Philip Guenther

Odd linking message (please relink your binary)

[Edd Barrett]

Hi,

I have this strange link message for xetex (Im building binaries for the
TL DVD, its nothing to do with the port). 

Take a look at this:
http://tug.org/pipermail/tlbuild/2008q3/000310.html

Does anyone have any clue what is happening here?

-- 

Best Regards
Edd

http://students.dec.bmth.ac.uk/ebarrett

Re: collect2: ld returned 1 exit status....during linking...

[Marc Espie]

On Tue, Apr 22, 2008 at 03:04:23PM -0700, vatocleti wrote:
> vatocleti wrote:
> > 
> > Hey all,
> >   I installed 'gmake' to build a Linux based Makefile that uses 'gcc' and
> > when I issue 'gmake' I get the following error:
> > 
> > /usr/bin/ld: my_app.o: relocation R_X86_64_32 can not be used when making
> > a shared object: recompile with -fPIC
> > my_app.o: could not read symbols: Bad value
> > collect2: ld returned 1 exit status
> > gmake: *** [libAPP.so] Error 1
> > 
> > any ideas/suggestions are greatly appreciated.
> > 
> > Thanks in advance.
> > 
> I added "-fPIC" to CLFAGS and this got me past this error...is that the
> proper fix?

More or less.

Re: collect2: ld returned 1 exit status....during linking...

[vatocleti]

vatocleti wrote:
> 
> Hey all,
>   I installed 'gmake' to build a Linux based Makefile that uses 'gcc' and
> when I issue 'gmake' I get the following error:
> 
> /usr/bin/ld: my_app.o: relocation R_X86_64_32 can not be used when making
> a shared object: recompile with -fPIC
> my_app.o: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> gmake: *** [libAPP.so] Error 1
> 
> any ideas/suggestions are greatly appreciated.
> 
> Thanks in advance.
> 
I added "-fPIC" to CLFAGS and this got me past this error...is that the
proper fix?

Thanks
-- 
View this message in context: 
http://www.nabble.com/collect2%3A-ld-returned-1-exit-statusduring-linking...-tp16825629p16826265.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.

collect2: ld returned 1 exit status....during linking...

[vatocleti]

Hey all,
  I installed 'gmake' to build a Linux based Makefile that uses 'gcc' and
when I issue 'gmake' I get the following error:

/usr/bin/ld: my_app.o: relocation R_X86_64_32 can not be used when making a
shared object: recompile with -fPIC
my_app.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
gmake: *** [libAPP.so] Error 1

any ideas/suggestions are greatly appreciated.

Thanks in advance.
-- 
View this message in context: 
http://www.nabble.com/collect2%3A-ld-returned-1-exit-statusduring-linking...-tp16825629p16825629.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.

Re: [OT] postgresql client with libpqxx from ports - linking problem

[Marius Hooge]

mcb, inc. wrote:

You did not use '-l' correctly then.  You have not specified
a library to link against hence the unresolved reference.
Get the -l correct and you will be on your way.

Exactly.
Well, I just figured out, that I have to use -lpqxx instead of -llibpqxx.a
Duh...

Thank you anyway and sorry for the noise.

Re: [OT] postgresql client with libpqxx from ports - linking problem

[Jacob Meuser]

On Tue, Mar 25, 2008 at 10:17:28PM +0100, Marius Hooge wrote:
> I think this is kind of offtopic, but google couldn't help and I don't 
> know where else I could ask.
> 
> I'd like to write a postgresql client in c++ with libpqxx from the ports 
> and can't get it to link.
> (If I recall correctly, the libpqxx port is only used by koffice.)
> I'm a little bit unexperienced with linking to other libraries, so it
> could be something very obvious and a goto to a manual sufficiently helpful.
> I'm running an approx. one week old snapshot on i386.
> 
> main.cpp:
> #include 
> int main(){
>  pqxx::connection Conn("dbname=test");
>  return 0;
> }
> 
> and I tried to compile it with:
> $ c++ -Wall -I /usr/local/include -L /usr/local/lib -o dbconntest main.cpp

I think you want

$ c++ `pkg-config --cflags libpqxx` `pkg-config --libs libpqxx` -o dbconntest 
main.cpp

or maybe

$ c++ `pqxx-config --cflags` `pqxx-config --libs` -o dbconntest main.cpp

not tested though

> and get this result:
> /tmp//ccG13636.o(.text+0x2b): In function `main':
> : undefined reference to `pqxx::connection::connection[in-charge](char 
> const*)'
> /tmp//ccG13636.o(.text+0x3d): In function `main':
> : undefined reference to `pqxx::connection::~connection [in-charge]()'
> collect2: ld returned 1 exit status
> *** Error code 1
> 
> I also tried to link directly via -l with no success.
> 
> Any help would be appreciated - thank you.
> 

-- 
[EMAIL PROTECTED]
SDF Public Access UNIX System - http://sdf.lonestar.org

[OT] postgresql client with libpqxx from ports - linking problem

[Marius Hooge]

I think this is kind of offtopic, but google couldn't help and I don't 
know where else I could ask.


I'd like to write a postgresql client in c++ with libpqxx from the ports 
and can't get it to link.

(If I recall correctly, the libpqxx port is only used by koffice.)
I'm a little bit unexperienced with linking to other libraries, so it
could be something very obvious and a goto to a manual sufficiently helpful.
I'm running an approx. one week old snapshot on i386.

main.cpp:
#include 
int main(){
 pqxx::connection Conn("dbname=test");
 return 0;
}

and I tried to compile it with:
$ c++ -Wall -I /usr/local/include -L /usr/local/lib -o dbconntest main.cpp

and get this result:
/tmp//ccG13636.o(.text+0x2b): In function `main':
: undefined reference to `pqxx::connection::connection[in-charge](char 
const*)'

/tmp//ccG13636.o(.text+0x3d): In function `main':
: undefined reference to `pqxx::connection::~connection [in-charge]()'
collect2: ld returned 1 exit status
*** Error code 1

I also tried to link directly via -l with no success.

Any help would be appreciated - thank you.

Re: Linking errors of "size mismatch"

[Federico Giannici]

After a lot of attempts and experimenting... I have just realized that 
those errors actually are simply warnings: the program correctly 
executes (it silently deamonize so I didn't noticed it)!


Apart the fact that I cannot understand why there is this 
incompatibility between two system libraries (libc from official release 
and libbind from official ports), anyway I'd like to know if there can 
be some problem due to those warnings.


Thanks.



Federico Giannici wrote:
I'm trying to compile version 3 of milter-greylist. Unfortunately in 
packages there is only version 2 and I NEED the new DNSBL feature.


As it appears that OpenBSD 4.0 resolver library is not thread-safe, I'm 
trying to link the program with libbind. To be sure I installed libbind 
from the official packages.


It compiles cleansy but when I run milter-greylist it exits with the 
following errors:


./milter-greylist:/usr/lib/libc.so.39.3: /usr/local/lib/libbind.so.2.0 : 
WARNING: symbol(__p_class_syms) size mismatch, relink your program
./milter-greylist:/usr/lib/libc.so.39.3: /usr/local/lib/libbind.so.2.0 : 
WARNING: symbol(_res) size mismatch, relink your program
./milter-greylist:/usr/lib/libc.so.39.3: /usr/local/lib/libbind.so.2.0 : 
WARNING: symbol(__p_type_syms) size mismatch, relink your program


Probably I made a really stupid error as the autoconfig doesn't works 
for OpenBSD and so I modified the Makefile by myself.


Somebody can give me an hint of what I made wrong?


Thanks.




--
___
__
   |-  [EMAIL PROTECTED]
   |ederico Giannici  http://www.neomedia.it
___

Linking errors of "size mismatch"

[Federico Giannici]

I'm trying to compile version 3 of milter-greylist. Unfortunately in 
packages there is only version 2 and I NEED the new DNSBL feature.


As it appears that OpenBSD 4.0 resolver library is not thread-safe, I'm 
trying to link the program with libbind. To be sure I installed libbind 
from the official packages.


It compiles cleansy but when I run milter-greylist it exits with the 
following errors:


./milter-greylist:/usr/lib/libc.so.39.3: /usr/local/lib/libbind.so.2.0 : 
WARNING: symbol(__p_class_syms) size mismatch, relink your program
./milter-greylist:/usr/lib/libc.so.39.3: /usr/local/lib/libbind.so.2.0 : 
WARNING: symbol(_res) size mismatch, relink your program
./milter-greylist:/usr/lib/libc.so.39.3: /usr/local/lib/libbind.so.2.0 : 
WARNING: symbol(__p_type_syms) size mismatch, relink your program


Probably I made a really stupid error as the autoconfig doesn't works 
for OpenBSD and so I modified the Makefile by myself.


Somebody can give me an hint of what I made wrong?


Thanks.

--
___
__
   |-  [EMAIL PROTECTED]
   |ederico Giannici  http://www.neomedia.it
___

Re: trouble with linking verlihub shared plugins (.so libs)

[Dmitij Lebed]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jacob Meuser wrote:
> On Sun, Jan 08, 2006 at 12:57:40PM +0300, Dmitij Lebed wrote:
> 
>>> you might want to try installing the libtool port/package and using
>>> 'make LIBTOOL=/usr/local/bin/libtool', instead of just 'make'.  not
>>> sure if that will fix this, but it might ..
>>>
>> I've started make LIBTOOL=/usr/local/bin/libtool and got
>>
>> libtool: compile: unable to infer tagged configuration
>> libtool: compile: specify a tag with `--tag'
> 
> error messages without the corresponding command are meaningless.
> 

Sorry =),

# make LIBTOOL=/usr/local/bin/libtool
make  all-recursive
Making all in src
/usr/local/bin/libtool --mode=link g++  -g -O2 -I/usr/src/include/
- -I/usr/local/www/mysql/include -DHAVE_MYSYS_NEW -I/usr/local/include
- -I/usr/local/include-o verlihub -L/usr/local/lib -lpcre
- -L/usr/local/www/mysql/lib -lmysqlclient -lz -lm -lc -lcrypto
- -L/usr/local/lib -lGeoIP  -pthread -rdynamic verlihub.o libverlihub.la
- -lssl -lcrypto
libtool: link: unable to infer tagged configuration
libtool: link: specify a tag with `--tag'
*** Error code 1
iD8DBQFDwPWloN5ZK8eGpqMRAmWNAJ9saT7c8+5tk2HtZkmVb1w+MlpeUgCfWeFW
WSq9IJ7rbdshOJRUUDF+Jdg=
=GTIN
-END PGP SIGNATURE-

Re: trouble with linking verlihub shared plugins (.so libs)

[Jacob Meuser]

On Sun, Jan 08, 2006 at 12:57:40PM +0300, Dmitij Lebed wrote:

> > you might want to try installing the libtool port/package and using
> > 'make LIBTOOL=/usr/local/bin/libtool', instead of just 'make'.  not
> > sure if that will fix this, but it might ..
> > 
> 
> I've started make LIBTOOL=/usr/local/bin/libtool and got
> 
> libtool: compile: unable to infer tagged configuration
> libtool: compile: specify a tag with `--tag'

error messages without the corresponding command are meaningless.

-- 
<[EMAIL PROTECTED]>

Re: trouble with linking verlihub shared plugins (.so libs)

[Dmitij Lebed]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jacob Meuser wrote:
> On Sun, Jan 08, 2006 at 01:58:19AM +0300, Dmitij Lebed wrote:
>> May be I wrote in wrong place, excuse me... :)
>> I've standard openbsd-3.8 on i386 machine.
>> I've compiled verlihub (dc++ hub - http://verlihub.sourceforge.net/).
>> In installation of this hub there are some plugins, which are shared
>> libraries and loaded when hub starts, but this plugins weren't linked in
>> .so libs. I got this messages:
>>
>> ...
>> /bin/sh ../libtool --mode=link g++  -g -O2 -I/usr/src/include/
>> -I/usr/local/www/mysql/include -DHAVE_MYSYS_NEW -I/usr/local/include
>> -I/usr/local/include-o libverlihub.la -rpath /usr/local/lib
>> -no-undefined -rdynamic -L/usr/local/lib -lpcre
>> -L/usr/local/www/mysql/lib -lmysqlclient -lz -lm -lc -lcrypto
>> -L/usr/local/lib -lGeoIP  -pthread cantiflood.lo casyncconn.lo
>> casyncsocketserver.lo  cban.lo cbanlist.lo ccallbacklist.lo
>> cchatconsole.lo ccmdr.lo  ccommand.lo cconfigbase.lo cconfigfile.lo
>> cconfigitembase.lo  cconfmysql.lo cconnchoose.lo cconndc.lo cconnpoll.lo
>>  cconnselect.lo cconntypes.lo cdbconf.lo cdcclients.lo  cdccommand.lo
>> cdcconf.lo cdcconsole.lo cdcproto.lo cdctag.lo  cfreqlimiter.lo
>> cgeoip.lo cinfoserver.lo cinterpolexp.lo  ckick.lo ckicklist.lo
>> cmeanfrequency.lo cmessagedc.lo cmutex.lo  cmysql.lo cobj.lo
>> coperator.lo cpcre.lo cpenaltylist.lo  cpluginbase.lo cpluginloader.lo
>> cpluginmanager.lo cprotocol.lo  cprotocommand.lo cquery.lo creglist.lo
>> creguserinfo.lo  cserverdc.lo csetuplist.lo ctempfunctionbase.lo
>> cthread.lo  cthreadwork.lo ctime.lo ctimeout.lo ctrigger.lo ctriggers.lo
>>  cusercollection.lo cuser.lo cvhplugin.lo cvhpluginmgr.lo
>> cworkerthread.lo script_api.lo stringutils.lo thasharray.lo
>> tpluginbase.lo -L/usr/local/lib -lGeoIP -lssl -lcrypto
>>
>> *** Warning: linker path does not have real file for library -lmysqlclient.
>> *** I have the capability to make that library automatically link in when
>> *** you link to this library.  But I can only do this if you have a
>> *** shared version of the library, which you do not appear to have
>> *** because I did check the linker path looking for a file starting
>> *** with libmysqlclient and none of the candidates passed a file format test
>> *** using a file magic. Last file checked:
>> /usr/local/www/mysql/lib/libmysqlclient.a
> 
> you need to build a shared libmysqlclient.
> 
>> *** Warning: linker path does not have real file for library -lsupc++.
>> *** I have the capability to make that library automatically link in when
>> *** you link to this library.  But I can only do this if you have a
>> *** shared version of the library, which you do not appear to have
>> *** because I did check the linker path looking for a file starting
>> *** with libsupc++ and none of the candidates passed a file format test
>> *** using a file magic. Last file checked: /usr/lib//libsupc++.a
>>
>> *** Warning: linker path does not have real file for library -lgcc.
>> *** I have the capability to make that library automatically link in when
>> *** you link to this library.  But I can only do this if you have a
>> *** shared version of the library, which you do not appear to have
>> *** because I did check the linker path looking for a file starting
>> *** with libgcc and none of the candidates passed a file format test
>> *** using a file magic. Last file checked:
>> /usr/lib/gcc-lib/i386-unknown-openbsd3.8/3.3.5//libgcc.a
> 
> looks like both libsupc++.a and libgcc.a are relocatable, but libtool
> is ignorant of that.
> 
> you might want to try installing the libtool port/package and using
> 'make LIBTOOL=/usr/local/bin/libtool', instead of just 'make'.  not
> sure if that will fix this, but it might ..
> 

I've started make LIBTOOL=/usr/local/bin/libtool and got

libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'
iD8DBQFDwOIOoN5ZK8eGpqMRAizZAKDL/D1hj15hFXyiohrP2pQMgCbGxgCeIeh0
jKC2Djh8HZW/Ny+Zgwf2YNM=
=efeu
-END PGP SIGNATURE-

Re: trouble with linking verlihub shared plugins (.so libs)

[Jacob Meuser]

On Sun, Jan 08, 2006 at 01:58:19AM +0300, Dmitij Lebed wrote:
> May be I wrote in wrong place, excuse me... :)
> I've standard openbsd-3.8 on i386 machine.
> I've compiled verlihub (dc++ hub - http://verlihub.sourceforge.net/).
> In installation of this hub there are some plugins, which are shared
> libraries and loaded when hub starts, but this plugins weren't linked in
> .so libs. I got this messages:
> 
> ...
> /bin/sh ../libtool --mode=link g++  -g -O2 -I/usr/src/include/
> -I/usr/local/www/mysql/include -DHAVE_MYSYS_NEW -I/usr/local/include
> -I/usr/local/include-o libverlihub.la -rpath /usr/local/lib
> -no-undefined -rdynamic -L/usr/local/lib -lpcre
> -L/usr/local/www/mysql/lib -lmysqlclient -lz -lm -lc -lcrypto
> -L/usr/local/lib -lGeoIP  -pthread cantiflood.lo casyncconn.lo
> casyncsocketserver.lo  cban.lo cbanlist.lo ccallbacklist.lo
> cchatconsole.lo ccmdr.lo  ccommand.lo cconfigbase.lo cconfigfile.lo
> cconfigitembase.lo  cconfmysql.lo cconnchoose.lo cconndc.lo cconnpoll.lo
>  cconnselect.lo cconntypes.lo cdbconf.lo cdcclients.lo  cdccommand.lo
> cdcconf.lo cdcconsole.lo cdcproto.lo cdctag.lo  cfreqlimiter.lo
> cgeoip.lo cinfoserver.lo cinterpolexp.lo  ckick.lo ckicklist.lo
> cmeanfrequency.lo cmessagedc.lo cmutex.lo  cmysql.lo cobj.lo
> coperator.lo cpcre.lo cpenaltylist.lo  cpluginbase.lo cpluginloader.lo
> cpluginmanager.lo cprotocol.lo  cprotocommand.lo cquery.lo creglist.lo
> creguserinfo.lo  cserverdc.lo csetuplist.lo ctempfunctionbase.lo
> cthread.lo  cthreadwork.lo ctime.lo ctimeout.lo ctrigger.lo ctriggers.lo
>  cusercollection.lo cuser.lo cvhplugin.lo cvhpluginmgr.lo
> cworkerthread.lo script_api.lo stringutils.lo thasharray.lo
> tpluginbase.lo -L/usr/local/lib -lGeoIP -lssl -lcrypto
> 
> *** Warning: linker path does not have real file for library -lmysqlclient.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libmysqlclient and none of the candidates passed a file format test
> *** using a file magic. Last file checked:
> /usr/local/www/mysql/lib/libmysqlclient.a

you need to build a shared libmysqlclient.

> *** Warning: linker path does not have real file for library -lsupc++.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libsupc++ and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /usr/lib//libsupc++.a
> 
> *** Warning: linker path does not have real file for library -lgcc.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libgcc and none of the candidates passed a file format test
> *** using a file magic. Last file checked:
> /usr/lib/gcc-lib/i386-unknown-openbsd3.8/3.3.5//libgcc.a

looks like both libsupc++.a and libgcc.a are relocatable, but libtool
is ignorant of that.

you might want to try installing the libtool port/package and using
'make LIBTOOL=/usr/local/bin/libtool', instead of just 'make'.  not
sure if that will fix this, but it might ..

-- 
<[EMAIL PROTECTED]>

trouble with linking verlihub shared plugins (.so libs)

[Dmitij Lebed]

May be I wrote in wrong place, excuse me... :)
I've standard openbsd-3.8 on i386 machine.
I've compiled verlihub (dc++ hub - http://verlihub.sourceforge.net/).
In installation of this hub there are some plugins, which are shared
libraries and loaded when hub starts, but this plugins weren't linked in
.so libs. I got this messages:

...
/bin/sh ../libtool --mode=link g++  -g -O2 -I/usr/src/include/
-I/usr/local/www/mysql/include -DHAVE_MYSYS_NEW -I/usr/local/include
-I/usr/local/include-o libverlihub.la -rpath /usr/local/lib
-no-undefined -rdynamic -L/usr/local/lib -lpcre
-L/usr/local/www/mysql/lib -lmysqlclient -lz -lm -lc -lcrypto
-L/usr/local/lib -lGeoIP  -pthread cantiflood.lo casyncconn.lo
casyncsocketserver.lo  cban.lo cbanlist.lo ccallbacklist.lo
cchatconsole.lo ccmdr.lo  ccommand.lo cconfigbase.lo cconfigfile.lo
cconfigitembase.lo  cconfmysql.lo cconnchoose.lo cconndc.lo cconnpoll.lo
 cconnselect.lo cconntypes.lo cdbconf.lo cdcclients.lo  cdccommand.lo
cdcconf.lo cdcconsole.lo cdcproto.lo cdctag.lo  cfreqlimiter.lo
cgeoip.lo cinfoserver.lo cinterpolexp.lo  ckick.lo ckicklist.lo
cmeanfrequency.lo cmessagedc.lo cmutex.lo  cmysql.lo cobj.lo
coperator.lo cpcre.lo cpenaltylist.lo  cpluginbase.lo cpluginloader.lo
cpluginmanager.lo cprotocol.lo  cprotocommand.lo cquery.lo creglist.lo
creguserinfo.lo  cserverdc.lo csetuplist.lo ctempfunctionbase.lo
cthread.lo  cthreadwork.lo ctime.lo ctimeout.lo ctrigger.lo ctriggers.lo
 cusercollection.lo cuser.lo cvhplugin.lo cvhpluginmgr.lo
cworkerthread.lo script_api.lo stringutils.lo thasharray.lo
tpluginbase.lo -L/usr/local/lib -lGeoIP -lssl -lcrypto

*** Warning: linker path does not have real file for library -lmysqlclient.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libmysqlclient and none of the candidates passed a file format test
*** using a file magic. Last file checked:
/usr/local/www/mysql/lib/libmysqlclient.a

*** Warning: linker path does not have real file for library -lsupc++.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libsupc++ and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/lib//libsupc++.a

*** Warning: linker path does not have real file for library -lgcc.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libgcc and none of the candidates passed a file format test
*** using a file magic. Last file checked:
/usr/lib/gcc-lib/i386-unknown-openbsd3.8/3.3.5//libgcc.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
...
/bin/sh ../libtool --mode=link g++  -g -O2 -I/usr/src/include/
-I/usr/local/www/mysql/include -DHAVE_MYSYS_NEW -I/usr/local/include
-I/usr/local/include-o libvhapi.la -rpath /usr/local/lib -module
-shared -dy script_api.lo  -lssl -lcrypto

*** Warning: linker path does not have real file for library -lsupc++.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libsupc++ and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/lib//libsupc++.a

*** Warning: linker path does not have real file for library -lgcc.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libgcc and none of the candidates passed a file format test
*** using a file magic. Last file checked:
/usr/lib/gcc-lib/i386-unknown-openbsd3.8/3.3.5//libgcc.a

*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module libvhapi.  Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application i

Re: problem with dynamic linking on amd64 or expected behaviour?

[Eric Faurot]

oops, I might have spoken a bit too quick: I didn't see the recent ld.so changes
and I didn't realize my amd64 snapshot was so old. I'll try with a
more recent one.

Sorry for the noise.

Eric.

problem with dynamic linking on amd64 or expected behaviour?

[Eric Faurot]

Hi,

I am stuck on the following dynamic linking problem: python-expat has
a pyexpat.so module that contains a complete expat implementation
(1.95.8). Now there is the _cairo.so python that depends on
libcairo.so and libfreetype.so (found in /usr/X11R6/lib) which in turn
is linked to /usr/X11R6/lib/libexpat.so.5.0 (1.95.6). With python on
amd64...

>>> import pyexpat; import cairo

... seems to work (maybe not for long though), but...

>>> import cairo; import pyexpat

... segfaults during pyexpat importation, because pyexpat init code
calls an XML_* function that is resolved in libexpat.so.5.0 (dlopen-ed
by cairo.so) instead of pyexpat.so.

The funny thing is that problem does not happen on powerpc. So, I
suspect that this is a "feature" of the dynamic linker, using a wrong
search path for symbols on amd64. I have tried to investigate a bit
but I am not knowledgeable enough about the linking business. Anyway,
I have traced of the ld.so activity for the different cases: (names
are --)

http://ekyo.nerim.net/openbsd/

The segfault happens at pyexpat.c:1970 "MYCONST(XML_ERROR_UNBOUND_PREFIX);".
XML_ErrorString() returns NULL in /usr/X11R6/lib/libexpat.so.5.0,
crashing strlen later.

Eric.